I’ve already blogged about Deploying on Azure Web Site with Database Project in the past, but in that article I showed how to accomplish it with customization of the Build Template. That technique is useful because quite often you need to run custom scripts or tools to do additional deploy related procedures to the site, but if your need is simply deploying schema change to an Azure Database with a Database Project you can accomplish it even without the need to touch the Build Workflow.

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.

Tags: Azure, Continuous Deployment

• Microsoft TFS Goes Mobile With Perfecto MobileCloud
• Configure Test Plans for Web Access in TFS 2012.2
• Getting Started with LibGit2Sharp
• Team Foundation Service Update – May 13
• Agilethought ALM Experts Present Free Visual STudio Webinars
• Known Issue and Workaround for TFS 2012 Update 3 RC1
• Quality Enablement with Visual Studio 2012

Gian Maria

• Better Multi User Support for Work Item Tracking in TFS 2012
• Naked ALM: starting with why and getting naked
• Help Content for the Agile Planning Tools gets a makeover with TFS CU2
• Visual Studio Update 2012.3 Update 3 “go-Live” CTP is now available
• Finding Event Subscriptions in TFS 2012 using Power Shell
• Testing Java and Cross Platform applications with Squish and Microsoft Test Professional
• Embracing SCRUM and CMMI in TFS 2012

Gian Maria

Tags: Visual Studio ALM

You already know that I’m a fan of NDepend because it is a really useful tool to have a deep insight on your code and especially to spot out troublesome areas in your project.

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.

Tags: NDepend

Thanks to Visual Studio Fakes is it possible to isolate your unit test and testing difficult to test code. Today I need to test a class that issues some Web Request around the internet and I’m concerned about testing the SUT when the web response contains some specific code like 404 (Not Found) or something.

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

Tags: Fakes, Unit Testing