First of all download the publishing profile from your azure site.

Figure 1: Download publishing profile from Azure Web Site

Once you have publishing profile, it can be imported in Visual Studio, just Right-Click on Project node inside Visual Studio and choose Publish. From there you can import publishing profile just downloaded and modify it for your need.

Figure 2: Importing publishing profile from Visual Studio

From the settings tab you have the option to specify a .dacpac file to update database schema.

Figure 3:  Use a .dacpac to deploy database schema changes

Unfortunately this configuration is good from direct publishing with Visual Studio, but to make it works during a TFS Build you need to do some manual modification. Once the modified publishing file is changed, you can find it inside Properties/PublishProfiles node of your project, and you can edit it with a simple XML Editor.

Figure 4: Modify the location of the dacpac to match the location this file will have during TFS build

The trick here is modifying the path of the .dacpac file to match its location in the build server during the build. Knowing the location is quite simple, usually I map an entire branch (trunk, main or some release branch) as root dir for the build

Figure 5: Workspace configuration of Deploy build

Now I need to examine the structure of project folders, suppose the trunk has a sub-folder called TailspinToys that contains my web site project I want to deploy (called Tailspin.WebUpgraded).

Figure 6: Folder structure of my project

When the build takes place, all build output (including all .dacpac files) are stored in a folder called bin that is one level above the folder you mapped in the build workspace. To locate the build file during publish, I need to go three folder up to locate the parent of the trunk (my project is in Trunk\TailspinToys\Tailspin.WebUpgraded) then adding bin and the name of the .dacpac file. So the location of dacpac file is ..\..\..\bin\xxxxx.dacpac as you can see in Figure 4. Do not worry if it seems complicated, it is just a matter of a couple of tentative to find the root folder .

Once the publish file was modified and checked-in you can use it in your build definition.

Figure 7: Choose your new publish file as a publishing profile for the build.

Now you can run the build and database linked to the Web Site will be automatically updated with the definition of your Database Project.

Gian Maria.

Gian Maria

Gian Maria

With version 4 it added a really cool capability called CQLinq or Code Query Linq; an amazing feature that permits you to query your code using LINQ stile queries. Basically after I’ve analyzed a solution I got presented with a simple dialog that asked me what I’m interested to do primarily with the result of the analysis.

This feature is really amazing because you can query your code to find almost everything. It would be really long to show you every capability of CQLinq, you can read about it in official documentation, but I want to give you just a taste of what you can achieve with it.

Here I’m simply selecting all the methods that contains more than 30 lines of code and in the select part I’m interested in the number of comment lines. Long methods are painful, but if you find a method of 40 lines with 30 lines of comment you are in trouble, because if a developer put so much comment in long method, surely there is some weird logic in it.

CQLinq is full of interesting features, as an example if you select from JustMyCode.Methods you are actually selecting only your code, and not code generated from UI Designer. This will permit you to focus primary on your code and avoiding to have the result of the query polluted by Designer generated code.

NDepend designer fully support intellisense and this really helps you to achieve the result in really little time, the result is immediately shown below the query as soon as the query compiles, and if you made some mistake you are immediately presented with a simple list of compiling errors that makes you understand what is wrong with the query.

As usual I think that NDepend is a must-to-have tool especially if you need to find problem in legacy code. I strongly suggest you to check out all the possibility on official documentation page, to have an idea of the capability of the tool.

You can also download a trial of the product to try out by yourself in your project.

Gian Maria.

If you simply right-click the reference to system assembly in your project and Add a fakes assembly, you probably will be annoyed by the fact that when you try to create a ShimHttpWebRequest you are not able to do it. When some shim are not available, the reason is usually due to some limitation of fakes library, so types are skipped when shims and stub code are generated (during compilation).

Apart not being able to use a shim of HttpWebRequest, when you add a fakes assembly to Visual Studio test project, you are actually asking to the fakes library to create a stub and a shim for every class of that assembly, and this can be a problem because

1. Your build time increase
2. Some classes probably will not be generated due to Fakes Limitation

Solution is simple, just locate the System.Fakes files under Fakes directory of your test project, they usually contain only the name of the assembly and nothing more. This is the default and basically it means: Create a shim and a stub for every type in that assembly. You should change that file to specify only the types you are really going to use in your Unit Tests. Es.

<Fakes xmlns="http://schemas.microsoft.com/fakes/2011/" Diagnostic="true">
  <Assembly Name="System" Version="4.0.0.0"/>
  <StubGeneration>
    <Clear />
  </StubGeneration>
  <ShimGeneration>
    <Clear />
    <Add FullName="System.Net.WebRequest!"/>
    <Add FullName="System.Net.HttpWebRequest!"/>
    <Add FullName="System.Net.HttpWebResponse!"/>
  </ShimGeneration>
</Fakes>

This code is actually instructing the Fakes library on what class you are going to use. In the above example I’m telling that I’m not going to use any Stub and I want to use Shim for WebRequest, HttpWebRequest and HttpWebResponse. If you specify only the classes you are really going to isolate, build time will be shorter, and there is much more possibility that shims gets generated.

Remember also that when you create fake library for System assembly you actually will get two distinct fakes configuration, one for system, and the other for Mscorlib.fakes. I usually modify the mscorlib.fakes in such a way.

<Fakes xmlns="http://schemas.microsoft.com/fakes/2011/">
  <Assembly Name="mscorlib" Version="4.0.0.0"/>
  <StubGeneration>
    <Clear />
  </StubGeneration>
  <ShimGeneration>
    
    
  </ShimGeneration>
</Fakes>

For some reason, I need not to clear ShimGeneration for Mscorlib entirely, because it will makes Unit Test stop with StackOverflowException in my system even if I’m not going to use any class for mscorlib.

Now I can write shim for HttpWebResponse

ShimHttpWebResponse res = new ShimHttpWebResponse();
res.StatusCodeGet = () => HttpStatusCode.NotFound;

This simple snippet created a fake response to identify a NotFound (404) web response. I can now proceed to isolate call to WebRequest to return that instance and write Unit Tests that isolates calls to WebRequest classes. A full possible test is the following.

[Test]
public void Verify_behavior_on_404()
{
    using (ShimsContext.Create())
    {
        SolrServer sut = new SolrServer("http://nonexistent.url.it/solr/blbalba");
        sut.Logger = NullLogger.Instance;


        ShimHttpWebResponse res = new ShimHttpWebResponse();
        res.StatusCodeGet = () => HttpStatusCode.NotFound;

        ShimWebException wex = new ShimWebException();
        wex.ResponseGet = () => res;

        ShimHttpWebRequest.AllInstances.GetResponse = url => { throw (WebException) wex; };
        sut.RawSearch("*:*", "id,name", 0, 100);
    }
}

With these few lines of code I’m telling that each request to all instance of HttpWebRequest should throw a specific WebException that will behave as I want. This absolutely invaluable if you need to test various response such of 403 if you are trying to simulate authentication or 500 if you need to simulate some particular error of called service. The good part of this kind of test is that the Sut was absolutely not designed to be unit tested. Here is the code in the Sut that is issuing call to Solr server

HttpWebRequest oRequest = (HttpWebRequest)WebRequest.Create(fullUrl);
if (Logger.IsDebugEnabled) Logger.Debug("Solar query " + fullUrl);
oRequest.Method = "GET";
HttpWebResponse oResponse = null;
try
{
    oResponse = (HttpWebResponse)oRequest.GetResponse();
}
catch (WebException e)

As you can see the code directly create an HttpWebRequest and issue a GET Request, but thanks to fakes library during the test the call to GetResponse are detoured to my test code.

Remember also that after Visual Studio Quarterly Update 2 fakes library is now available even in Premium edition and not only Ultimate.

Gian Maria

Gian Maria

Solr is used not as a primary data store because it is a Search Platform whose primary purpose is giving the ability to do complex searches with blazing performance. This means that you usually have your data in a primary data store, Es. Sql Server and you need to move data to a Solr server to power up your searches.

Quite often you do not need real-time update, you can simply update your solr server nightly, or at given interval (update each X hours). In this scenario there is not the need to setup a mechanism that immediately replicate modification of Primary data store to Solr and you can rely on DIH: Data Import Handler. Suppose you have your data inside a Sql Server inside a table called tag; the first operation you need to do is locating all jar libraries that are needed to use DIH with Solr.

Figure 1: Copy all needed library inside the lib folder of core home directory

I use Solr with multi core configuration, my solr test instance is installed in c:\solr\TestInstance and inside that root directory I have multiple cores used to run different schema and configurations. Inside each core you should create a lib directory to store all jar files are needed for that specific core. To run DIH you need to copy apache-solr-dataimporthandler and apache-solr-dataimporthandler-extras taken from solr main distribution (zipped file you download from Apache Solar site). I’ve added also sqljdbc4.jar that contains classes needed to connect to a SqlServer database from java jdbc.

First step is creating the Data Import configuration file, to specify how you want to import data inside your Solr.

dataConfig>  
	<dataSource type="JdbcDataSource" 
			driver="com.microsoft.sqlserver.jdbc.SQLServerDriver" 
			url="jdbc:sqlserver://10.0.0.102;databaseName=Dictionary;" 
			user="sa" 
			password="xxxxxxxx" 
			batchSize="5" /> 
			
    <document name="TestDocument">  
        <entity name="TestEntity" query="SELECT * FROM tag">  
			<field column="Id" name="id" />
            <field column="Term" name="term" />  
            <field column="Name" name="name" />  
        </entity>  
    </document>  
</dataConfig> 

I usually call this file data-import.xml but you can use whatever name you want. DataSource node is used to specifies class of the driver to use, connection string with username and password and other option, Es batchSize to specify how many row at a time should be fetched from the data store. Once you have defined a DataSource you should at least specify one Document containing one entity, where each entity is composed at least by a query and a series of fields. The query is the simple SQL code that will be issued to the Data Store and fields are used to specify mapping from column of the query and field in schema.xml of that core.

This is the minimal configuration that is used to load data from Sql Server to Solr, after you created this file you need to specify the handler inside the solrconfig.xml file.

<requestHandler name="/dataimport" class="org.apache.solr.handler.dataimport.DataImportHandler">     

	<lst name="defaults">    
		<str name="config">data.import.xml</str>  
	</lst>    
</requestHandler>  

Now everything is in place, you can go to the Dataimport section of the core you configured and you can execute the import handler.

Figure 2: Import data with standard solr web interface.

You can now check that after the import solr contains data you expect.

Figure 3: Simple *:* query to verify that data was really imported from the DIH

Thanks to few xml lines of code you are able to import data from Sql Server to Solr without the need to write a single line of code.

Gian Maria.