First, inside Visual Studio 2012, code coverage is enabled by default. Those settings go with the unit test explorer, so they rely more on the “runsettings” file—if you even have one. If you want to customize that, check out this post.

For the build, first edit the build definition, and go to the “process” tab:

When you click on the ellipsis (“…”) next to “Automated Tests”, you’ll get this editor:

Click on the “Edit” button and you’ll get the following dialog:

Under “Options”, choose “Enable Code Coverage”. You may also want to fail the build if your unit tests fail. Keep clicking “OK” all the way out of the dialogs that were opened, and save your build definition.

The Modern Application Lifecycle presentation was high-level, and went over what a modern app is, the timelines for modern “Systems of Engagement” applications, and the application lifecycle that supports them. I believe Matt Nunn recorded a similar session at Taking your business forward with Modern apps.

The DevOps slide deck is very short—we spent almost all the time on 3 demos. The demo VM’s aren’t publicly available, but it looks like a similar session is recorded at DevOps with System Center and Visual Studio.

You can find my slides posted at sdrv.ms/S0cVdu.

Also, Zain Naboulsi has a lot of tips for Visual Studio 2010 at https://channel9.msdn.com/Niners/VSTips.

If you’re a IT manager or decision maker, a project manager on software projects, a professional developer, or a tester, there should be something at the event for you.

The presentation will be almost entirely a demo of Visual Studio running live, and the content is suitable for virtually any role within your software development organization. We’ll show how Visual Studio 11 brings together everyone involved in a software project – business analysts, project managers, developers, testers, operation staff and end-users. We’ll demonstrate envisioning, scoping, building, testing, deploying, and diagnostics throughout the three key phases of software management: Definition, Delivery and Operations.

To register, click on one of the links below and fill out the form to register for your local event.

Hope you can make it,

David

The imported project "C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\Windows Azure Tools\1.6\Microsoft.WindowsAzure.targets" was not found. Confirm that the path in the <Import> declaration is correct, and that the file exists on disk.

The install of Visual Studio 11 was causing my $(VisualStudioVersion) environment variable to be overridden. For the most part, this was OK, but the Azure toolkit isn’t available for the CTP of Visual Studio 11, so that target file doesn’t exist.

I went out to this link, and saw that I needed to set the VisualStudioVersion as a parameter.  According to the article:

These new methods also take a VisualStudioVersion enumerated value as a parameter to determine which tool subset to use. The VisualStudioVersion enumeration can have one of the following values:

• VisualStudio10

• VisualStudio11

• VisualStudioLatest

Setting /p:VisualStudioVersion=VisualStudio10 resulted in:

The imported project "C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\vVisualStudio10\Windows Azure Tools\1.6\Microsoft.WindowsAzure.targets" was not found. Confirm that the path in the <Import> declaration is correct, and that the file exists on disk.

So I tried “/p:VisualStudioVersion=v10.0”, but I missed that the tool prepended a “v” prefix for me.

Finally I tried “/p:VisualStudioVersion=10.0” and found success! 

So, there’s a nice tip for my toolbox.

I tried a few things, such as removing the property setters, but that prevented the DbSet from persisting those properties. I could have written a custom mapping, but that really felt like overkill. Setting Editable annotations never worked for me. Finally, I marked the appropriate setters as “internal”, and had more success.

This isn’t enterprise code, but you can see where I’ve used “internal” to protect some settings. Since the data context is in the same namespace but the view isn’t, the properties are safe from end user editing. 

I’ve also set a few methods to set properties for me. For example, I have Approve and Reject methods which change the status. It’s a lightweight workflow, and would be better to handle another way, but this was a quick-and-dirty approval system and it works well enough.

public class PurchaseRequest
    {
        private string userName;
        private DateTime requestDate;
        private string status = "PENDING";

        public int PurchaseRequestId { get; set; }

        public string UserName { get { return userName; } internal set { userName = value; } }
        public string Title { get; set; }

        public DateTime RequestDate { get { return requestDate; } internal set { requestDate = value; } }
        public virtual ICollection<OrderItem> OrderItems { get; set; }

        public string Status { get { return status; } internal set { status = value; } }

        public void Init(string user)
        {
            userName = user;
            requestDate = DateTime.Now;
            status = "PENDING";
        }

        public bool CanApprove()
        {
            if ("PENDING".Equals(status))
            {
                return true;
            }
            else
            {
                return false;
            }
        }

        public void Approve()
        {
            if (CanApprove()) status = "APPROVED";
        }

        public void Reject()
        {
            if (CanApprove()) status = "REJECTED";
        }

    }

1. Find MSBuild extensions for the various BIDS projects. They’re out there.
2. Run the build through Visual Studio—a “DevEnv” build.

I chose the second option. I downloaded the latest Community TFS Build Extensions and followed the instructions to add the activities to the workflow and the toolbox.  The activity I cared about was the “VSDevEnv” activity, and that’s in the TfsBuildExtensions.Activities.dll assembly.  I added it to a new tab called “Team Build Contributions” (VSDevEnv is the fourth activity):

I copied the DefaultTemplate.xaml file into a DevEnvTemplate.xaml. You can navigate down to a subworkflow called “Process > Sequence > Run on Agent > Try Compile and Test > For Each Configuration > Compile and Test > if Build Settings … > For Each Project … > Try to Compile … > Compile the Project”. In it, there is an option called “Run MSBuild for Project”.  I removed the “Run MSBuild for Project” activity shown below:

and I replaced it with the “VSDevEnv” extension activity. I added the “Copy Directory” activity, since the MSBuild activity copies the binaries to a drop and the VSDevEnv activity doesn’t.  You can see the new flow in the picture below:

I added the BIDS DevEnv path to my global “path” variable on the system, but you can add it to the user path on the build server. I also tagged the build server with “BIDS08” to direct the build to a machine that could support that build.

I had to set the input path—”localProject” already had the name of the file I was trying to build; set it to the project if you can rather than the solution.

The “OutputFile” is the log file from the build. I set that to outputDirectory + "\" + System.IO.Path.GetFileName(localProject) + ".log". 

For “CopyDirectory”, I used BinariesDirectory as the Destination, and I used System.IO.Path.GetDirectoryName(localProject) + "\bin\" as the input directory.

At the end, I had all four of my Analysis Service build assets in the drop folder. Hopefully, I can tackle deployment in another post.

You’ll need to add a reference to the System.Configuration assembly for that to work. Adding annotations to validate the properties would also be a good idea.

Then I added the custom elements to my app.config file (which I added to my test project):

The “type” attribute is “[Configuration Class], [assembly holding your extension without the dll/exe suffix], [version], [culture], [key]”.

Next, I created a helper class to format the URL for me:

And I called the helper class to replace the recorded URL with the configured one (see lines 1 and 7 below):

There are more properties you’d want to overload, but I haven’t done that here. Vishal Joshi has a blog post that describes how to transform the app.config file for different build configurations, and that’s something else I’d like to do.

Some housekeeping is probably a good idea, but this is just a simple example.

Nicely, the SysInternals ProcDump tool gives you a 32-bit minidump by default, or you can ask it to give you a 64-bit minidump. Nicely, you can attach it to the process and have it write a log automatically when the process hangs for 5 seconds, like

C:\>procdump -h hang.exe hungwindow.dmp

It helped me out yesterday.

First, you can add the alias to your machine by using the command-line tool “netdom” and then updating your DNS records:

C:\> NETDOM COMPUTERNAME <primary machine name> /Add <newname.domain.com>

C:\>IPCONFIG /REGISTERDNS

There are other options described at “Adding IIS Host Headers in DNS using Netdom utliity” and “Multiple names for one computer - Consolidate your SMB file servers without breaking UNC paths”.

Then you go into the IIS Console, create a new site, and set the site binding to use the new host name