Donovan Brown

Technology Blog

Increase the reach of Code Lens and Code Map

30 May 2014 Donovan-Brown Work (0)
Problem: My code lens does not see references to properties in my MVC views .cshtml files. Solution: Install the Razor Generator extension. Explanation: While watching a great deep dive of Code Map by Jean-Marc Prieur he mentioned the Razor Generator as a way to enable features in Code Map and Code Lens. Install both the Razor Generator Extension and the Razor Generator MVC nuget package.  Once the nuget package is installed you can run the Enable-RazorGenerator command from the Package Manager Console. This will cause the Razor Generator to update all your cshtml files so they use a custom tool installed by the Razor Generator extension.   This extension allows processing Razor files at design time instead of runtime, allowing tools like Code Map and Code Lens to walk the code and find the references. Before: Code Lens showing only 2 references After:   Code Lens showing 3 references   Code Map showing the view

I can't register the Microsoft Deployment Agent 2013

11 May 2014 Donovan-Brown Work (0)
Updated: With update 2 the deployer account no longer as to be an admin on the machine.  The account simply needs to correct permissions to deploy the desired components.   Problem: When I attempt to register my deployer I get a 401 unauthorized error.   Solution: Make sure the account you are using is an Administrator on the deployer machine and added to Release Management on the Server. Also the account running the installer must have access to the Sql Server on the Release Server machine.

Start and stop Hyper-V VMs from Release Management

06 May 2014 Donovan-Brown Work (0)
While preparing my Demo for TechEd North America 2014 on Release Management I ran into a challenge that required me to add additional custom tools. I thought I would blog about one of the tools I decided to add. One of the goals of my Release Management demo was to deploy to Azure which is an amazing cloud service from Microsoft.  I was able to get the demo to work perfectly from home.  Then I realized that I would not be able to have the network at the George R. Brown Convention Center, where TechEd was being held, to forward port 1000 to my laptop. This would be a requirement so the Microsoft Deployer Agent running on my Azure VM would be able to connect to the Release Management Server on my laptop. I really wanted to be able to show how you could use a Proxy Deployer to start and stop a virtual machine as part of your deployment.  However, I would have to show this in a way that would not have me rely on the network being configured to forward port 1000 to my laptop.  I got the idea to substitute Hyper-V for Azure.  If I could start and stop a Hyper-V VM as part of my demo the attendees would be able to witness the full workflow with Hyper-V playing the role of Azure for the demo.  To make this work I was going to have to add a custom tool to Release Management that would be able to start and stop VMs in Hyper-V just like Release Management does out of the box for Azure.  One of the things that makes Release Management such a great tool is how easy it is to extend and add new tools.  All I would have to do is add a custom PowerShell script that can start and stop Hyper-V VMs. PowerShell was designed for system administration, built on the .NET Framework.  It allows Windows users to control and automate many aspects of Windows.  PowerShell is also a pillar in the foundation of Release Management.  If you can write a PowerShell script to perform any task than that task can be performed during a deployment with Release Management. Many technologies create PowerShell modules that contain functionality you can use to control the technology.  Hyper-V is no exception. If you have the Hyper-V role enabled on a Windows 8 or Windows Server 2012 machine you have a PowerShell module for Hyper-V you can use to perform all sorts of tasks with Hyper-V.  I used that module to create a PowerShell script I could use to start and stop VMs in Hyper-V.  You can download the script below. Once I created the script using the Windows PowerShell Integrated Scripting Environment (ISE) it was time to add it to the Release Management tool inventory.  You can add a tool to Release Management using the procedure described below. Open the Release Management client. From the Inventory tab select Tools. Click New and enter the following information: Name: Hyper-V VM Controller Description: Start and Stop Hyper-V VMs Command: powershell Aruguments: -File ./ControlHyperVVM.ps1 -Command ACTION -ComputerName __ComputerName__ -Name __Name__ Click the Add button under the Resources section. Select all the required files.  This could be an executable and the required assemblies, a batch file or in this case just the PowerShell file.  All the resources are copied to the Deployer Agent when required. Now click Save & Close. Once the tool has been added to the Tools Inventory we can add Actions to the Inventory as well.  Release actions define the deployment sequence for each stage of your release.  An Action is defined by the tool and a set of arguments.  We are going to add two actions using the newly added Hyper-V VM Controller tool added above. Open the Release Management client if not open already. From the Inventory tab select Actions. Click new and enter the following information. Note how we change the place holder "ACTION" defined when we added the tool to the actual action we wish to perform.  You will also have to add the Hyper-V category by clicking New next to the Categories drop down. Add the Start Action Name: Hyper-V VM - Start Description: Start a VM in Hyper-V Categories: Hyper-V Tool: Hyper-V VM Controller Arguments: -File ./controlHyperVVM.ps1 -Command Start -ComputerName __ComputerName__ -Name __Name__ Add the Stop Action Name: Hyper-V VM - Stop Description: Stop a VM in Hyper-V Categories: Hyper-V Tool: Hyper-V VM Controller Arguments: -File ./controlHyperVVM.ps1 -Command Stop -ComputerName __ComputerName__ -Name __Name__ With the tool and actions added you can now create a release sequence using these actions to start and stop a Hyper-V VM. ControlHyperVVM.ps1 (3.18 kb)

Stop and deallocate an Azure VM from Release Management

30 April 2014 Donovan-Brown Work (0)
Problem: While trying to start an Azure VM from Release Management I get the following error: "ERROR: Windows Azure PowerShell Cmdlets is not installed." Even though I followed all of the instructions here. Solution: There are actually two solutions.  First is update the "PSModulePath" environment variable by removing the "Azure\" from the "C:\Program Files (x86)\Microsoft SDKs\Windows Azure\PowerShell\Azure\" portion.  It appears that the ControlAzureVM.ps1 file that ships with Release Management Update 2 RC appends the "Azure\" itself. If it is already in the path it will fail.  I am not sure if the latest Azure SDK has change this value or not. I decided not to modify the environment variable for fear that it might break other parts of the Azure SDK.  So I took this opportunity to write my own ControlAzureVM.ps1 file that honors the environment variable as it is set by the SDK.  I also decided to enhance the script to not only support Start and Stop but to also support Shutdown of a VM.  Stopping a VM will place it in the Stopped state.  Unfortunately this means you are still being charged compute hours for that VM.  Only Azure VMs in the Stopped (Deallocated) state are free.  Therefore, I added a new Action for Shutdown that will deallocate your VM as well.  You can download the PowerShell file below. Simply add the PowerShell script as a new tool.  Copy all of the values for the settings from the out of the box Azure tool. Then added three new Actions. One for Start, Stop and Shutdown using the new tool. Noticed the "ACTION" place holder of the tool is replaced in each action. ControlAzureVM.ps1 (6.05 kb)

Can't deploy Through Release Management Server over HTTP(S)

17 April 2014 Donovan-Brown Work (0)
Problem: Configuring the “Drop Location Access” as “Through Release Management Server over HTTP(S)” with Release Management I get the following error:“Message: Could not load file or assembly 'Newtonsoft.Json, Version=4.5.0.0, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed' or one of its dependencies.” Solution: Copy Newtonsoft.Json.4.5.1, net40 into the bin folder of Release Management “C:\Program Files (x86)\Microsoft Visual Studio 12.0\Release Management\bin”. To get a copy of the correct version of newtonsoft.json I created a class library project in Visual Studio and issued this command from the package manager console:“Install-Package Newtonsoft.Json -Version 4.5.1” Then I copied the file from the packages folder “Newtonsoft.Json.4.5.1\lib\net40”.

I can't use email as Username with MVC5 Microsoft.AspNet.Identity

09 March 2014 Donovan-Brown Work (0)
Problem: I want to use email as the username with Microsoft.AspNet.Identity in MVC 5 application. But when I do I get the following error: User name ... is invalid, can only contain letters or digits. Solution: In the AccountController constructor that takes a userManager as a parameter add the following code: UserManager.UserValidator = new UserValidator<ApplicationUser>(UserManager)  { AllowOnlyAlphanumericUserNames = false };

Find by Status is not working

13 February 2014 Donovan-Brown Work (0)
Problem: "Find by Status" of the TFS Power Tools always returns zero results even though people have files checked out.    Solution: Make sure the developers workspaces are Server and not Local. Explanation: Only Server workspace communicate the status of check outs back to the Server local workspaces do not.  

Running Microsoft Test Manager Suite with Release Management

25 January 2014 Donovan-Brown Work (0)
Goal I want to run a Microsoft Test Manager Suite after my bits are deployed by Microsoft Release Management (InRelease). Solution: There appears to be a bug in the current "MTM Automated Tests Manager" tool that will fail if your build definition name contains spaces. So I took this opportunity to write my own PowerShell script to run as part of my deployment within Release Management.  Attached to this post is a PowerShell script that corrects the space issue. The remainder of this post will explain how to add a new tool to Release Management and add a testing component to your release template. Begin by starting Release Management and clicking the Inventory tab then Tools.  Once on the Tools tab under Inventory click the New button.  Feel free to enter any Name and Description you like.  For the command simply type “powershell”. For the Arguments value enter: -command ./MyTcmExec.ps1 -Collection __Collection__ -TeamProject __TeamProject__ -PlanId __PlanID__ -SuiteId __SuiteID__ -ConfigId __ConfigID__ -BuildDirectory __BuildDirectory__ -Title __Title__ If you took the time to read the MyTcmExec.ps1 file you may have noticed not all the parameters are listed in the arguments above.  That is because not all of the arguments are required to have a successful test run. However, if you need to pass in the additional parameters for your situation simply add them to the Arguments.  Each value that begins and ends with double underscore “__” will be assignable on each stage. Now that we have our tool in Release Management lets create a component that uses our tool.  Click the Configure Apps tab then Components. Once on the Components tab under Configure Apps click the New button.  Feel free to enter any Name and Description you like.  On the Source tab simply enter a \ for the Path to package value.  On the Deployment tab is where we select our tool from the Tool dropdown.  Unless you would like to adjust the arguments for this component simply click Save & Close.  Note that any changes to the arguments will only affect this component and not the tool definition. The final step is to add the component to our release template. Click the Release Template tab under Configure Apps.  Right click on Components in the Toolbox and select Add from the context menu.  Select the desired component and click the Link button or simply just double click the component to add it to the toolbox.  Now simply drag and drop the new component to the desired location in your stage’s workflow. Although Release Management has helper variables for example $(PackageLocation), $(TfsUrlWithCollection) and $(TeamProject). I discovered the $(TfsUrlWithCollection) and $(TeamProject) variables do not expand to the expected values.  $(TfsUrlWithCollection) includes the team project and $(TeamProject) expands to an empty string. Therefore, I suggest you simply hardcode those values with the exception of $(PackageLocation) which appears to work as expected. You will have to harvest the PlanID, ConfigID and SuiteID from Microsoft Test manager.  Use the images below to locate those values.  You will also need the URL to the Team Project Collection and the name of the Team Project. Using the values from Microsoft Test Manager and TFS you can now fill in the values of your component.  You can enter any value you like for the Title.  For the BuildDirectory enter $(PackageLocation). The final step is to make sure you have associated automation to test case in your selected suite and the assembly that contains that automation is being built with the solution being released.  Good luck. MyTcmExec.ps1 (6.17 kb)