Resizing a virtual hard disk
Recently, I had to resize a VHD (virtual hard disk) that I installed Windows Server 2008 on. I soon found out that the size of 10GB is not such a hot idea when installing Team Foundation Server 2010 and SQL Server 2008 on the same instance. Hence, I decided to resize the disk instead of re-installing all of the software.
Below is the recipe to resize the virtual hard disk:
Part 1:
The first part is to resize the container of the partition, which is done by means of a sector copy. After the resize completed, the container will have increased but the partition will not be fully extended yet.
- Download VHD Resizer from VMToolkit.
- Install and run VHD Resizer.
- In the file open dialog select the VHD that you want to resize.
- Type in the new filename to use for the extended VHD.
- Type in the size of the new container to create.
- Click on Resize. The process takes a few minutes…
Part 2:
Now that the container is resized, we must now extend the partition to make use of the full container size.
- Attach the new extended VHD as a non-primary drive to another virtual machine. Do not extend the partition using the virtual machine that will make use of it.
- Start the virtual machine to which the extended VHD was attached as the non-primary drive and open a command prompt.
- Type in diskpart and press Enter.
- Type in list disk.
- Ensure that disk 1 or greater is the extended disk.
- Type in select disk 1.
- Type in list partition.
- Ensure that the partition sizes matches the old size.
- Type in extend.
- Wait for the process to complete and type exit.
Remember to change the disk on the original virtual machine to now use the extended disk. The disk is now resized and ready to be used from the original virtual machine.
Mocking multiple interfaces using Rhino Mocks
A while back on StackOverflow I asked a question on how to create a mock object with Rhino Mocks that implements multiple interfaces. In other words, I want to generate a mock that implements more than one interface. This baffled me for a while and I was shown the light by one of my colleagues.
A multi-mock is created like so:
var mocker = new MockRepository(); var mock = mocker.CreateMultiMock<IPrimaryInterface>(typeof(IFoo), typeof(IBar)); mock.Expect(x => x.AnswerToUniverse()).Return(42); mocker.ReplayAll();
Note the call to ReplayAll. Without this call the mock will not be setup with the intended values.
Unit test deployment issue when file is untrusted
Recently, I decided to use NHibernate in a project so that I could achieve database affinity. That provided me with another benefit and that was the ability to create a database in-memory for testing purposes. Sounded great, but while trying to run the unit tests using MsTest and SQLite, I received the following error: “Test Run deployment issue: The location of the file or directory ‘C:\projects\myproject\SQLite\sqlite3.dll’ is not trusted.“.
That problem was easily solved by simply unblocking the file. Below are the steps on how to unblock the file:
- Right-click the blocked file (sqlite3.dll), and then click Properties.
- This will open the properties dialog:
- In the General tab, click Unblock.
- Click on OK.
That’s it, the file is now trusted and the runtime should be able to load the file successfully.
Automating a ClickOnce Deployment – Part3
Continuing the series on Automating a ClickOnce Deployment it’s time to implement the deployment scheme in a build file.
After the build file compiled the solution we are ready to start the copying of the installation files to the deployment server. Before we start the copy process we have to create a new directory for the new application version. In the following snippet I simply generate a new version number and then create a directory where we will copy the installation files to:
<Target Name="DeployApplication"> <Message Text="Deploying the client application to $(PublishServer)" /> <MakeDir Directories="$(DeploymentServer)\Published\App\$(VersionNumber)" />
We are ready to copy the application files to the server:
<Message Text="Copying files to deployment directory [$(DeploymentServer)\Published\App\$(VersionNumber)]" /> <Copy DestinationFiles="@(ApplicationFiles->'$(DeploymentServer)\Published\App\$(VersionNumber)\%(Filename)%(Extension)')" SourceFiles="@(ApplicationFiles->'$(BinariesFolder)\%(Filename)%(Extension)')" />
The ApplicationFiles is an item group with the installation files that we are copying. Note: we do not transform the filename to include the .deploy extension because we first need to generate the deployment manifest with the files in the right location before changing the name of the files. (See Gotcha #3). Next, we create the application manifest with the Mage utility which will be stored in the application directory (not in the version directory). Mage is a manifest generator and is used to generate both application and deployment manifests. In the snippet below we are using Mage explicitly to generate the application manifest:
<CreateProperty Value="$(DeploymentServer)\Published\App\$(VersionNumber)\App.exe.manifest"> <Output TaskParameter="Value" PropertyName="ApplicationManifestFile"/> </CreateProperty> <Message Text="Generating application manifest [$(ApplicationManifestFile)] using [$(DeploymentServer)\Published\App\$(VersionNumber)]" /> <Exec Command="mage.exe -New Application -p msil -TrustLevel FullTrust -ToFile $(ApplicationManifestFile) -Name "App" -Version $(VersionNumber) -FromDirectory $(DeploymentServer)\Published\App\$(VersionNumber)" />
So far so good, we have now managed to generate the deployment manifest from the files located in the …\Published\App directory and placed the file in the …\Published\App\$(VersionNumber) directory. We will now point the application manifest to this deployment manifest so that the correct files are installed on the client machine.
We now have everything that we need in order to generate the application manifest.
<CreateItem Include="$(ApplicationManifestFile)" AdditionalMetadata="TargetPath=$(VersionNumber)\App.exe.manifest"> <Output TaskParameter="Include" ItemName="RelativeApplicationManifestFile"/> </CreateItem> <GenerateDeploymentManifest AssemblyName="App.exe.application" AssemblyVersion="$(VersionNumber)" DeploymentUrl="http://deployment-server/Published/App/App.exe.application" Product="App" Description="App" Publisher="thirdshelf.com" Install="true" UpdateEnabled="true" UpdateMode="Foreground" OutputManifest="$(DeploymentServer)\Published\App\App.exe.application" MapFileExtensions="true" EntryPoint="@(RelativeApplicationManifestFile)" />
If you read part 2 of this series you should be able to map these properties straight to their positions in the application manifest file and their functions. The only thing that remains is to rename the files to include their .deploy extensions. This can easily be done in the following way:
<Message Text="Replacing files in [$(DeploymentServer)\Published\App\$(VersionNumber)\] with [.deploy]" /> <Delete Files="@(ApplicationFiles->'$(DeploymentServer)\Published\App\$(VersionNumber)\%(Filename)%(Extension)')" /> <Copy SourceFiles="@(ApplicationFiles->'$(BinariesFolder)\%(Filename)%(Extension)') DestinationFiles="@(ApplicationFiles->'$(DeploymentServer)\Published\App\$(VersionNumber)\%(Filename)%(Extension).deploy')" />
Visiting the URL http://deployment-server/Published/App/App.exe.manifest and clicking on the Install button you should see the following dialog:
Gotchas
There are a few gotchas that you might find on your way to success and I’ve listed the most common ones here and their solutions for your convenience:
Gotcha #1: Reference in the manifest does not match the identity of the downloaded assembly …
This is easily resolved by adding the NoWin32Manifest property to solution in the SolutionsToBuild group:
<SolutionToBuild Include="$(SolutionRoot)\Application.sln"> <Properties>NoWin32Manifest=true</Properties> </SolutionToBuild>
Gotcha #2: XML files are marked as data files, by default.
This means that XML files are published to the data directory whose location can found by querying the System.Deployment.Application.ApplicationDeployment.CurrentDeployment.DataDirectory property.
Gotcha #3: The customHostSpecified attribute is not supported for Windows Forms applications.
Not a very helpful error, but chances are that you generated the deployment manifest with the installation files having the .deploy extension and not on the original filenames.
Automating a ClickOnce Deployment – Part2
Continuing the series on Automating a ClickOnce Deployment it’s time to have a look at the manifest files. There are two required manifest files that give clickonce the necessary information to deploy the application:
- an application manifest (.application);
- a deployment manifest (.manifest).
Application Manifest
The application manifest describes the application that we are going to install. So, let’s have a look at the contents of this file:
xml version="1.0" encoding="utf-8"?>
<asmv1:assembly xsi:schemaLocation="urn:schemas-microsoft-com:asm.v1 assembly.adaptive.xsd" manifestVersion="1.0" xmlns:asmv3="urn:schemas-microsoft-com:asm.v3" xmlns:dsig="http://www.w3.org/2000/09/xmldsig#" xmlns:co.v1="urn:schemas-microsoft-com:clickonce.v1" xmlns="urn:schemas-microsoft-com:asm.v2" xmlns:asmv1="urn:schemas-microsoft-com:asm.v1" xmlns:asmv2="urn:schemas-microsoft-com:asm.v2" xmlns:xrml="urn:mpeg:mpeg21:2003:01-REL-R-NS" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<assemblyIdentity name="App.application" version="1.0.903.18476" publicKeyToken="0000000000000000" language="neutral" processorArchitecture="msil" xmlns="urn:schemas-microsoft-com:asm.v1" />
asmv2:publisher="App Publishers Company" asmv2:product="App" xmlns="urn:schemas-microsoft-com:asm.v1">App
mapFileExtensions="true">
<subscription>
<update>
<beforeApplicationStartup />
</update>
</subscription>
<deploymentProvider codebase="http://deployment-server/Published/App/app.exe.application" />
</deployment>
<dependency>
<dependentAssembly dependencyType="install" codebase="1.0.903.18476\App.exe.manifest" size="33600">
<assemblyIdentity name="App.exe" version="1.0.903.18476" publicKeyToken="0000000000000000" language="neutral" processorArchitecture="msil" type="win32" />
<hash>
<dsig:Transforms>
<dsig:Transform Algorithm="urn:schemas-microsoft-com:HashTransforms.Identity" />
</dsig:Transforms>
<dsig:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
<dsig:DigestValue>DrLiyVjtlKhOmtuzuXhFSTqi/9Q=
</hash>
</dependentAssembly>
</dependency>
</asmv1:assembly>
One of the important things to note in this manifest is the mapFileExtensions attribute in the deployment tag. This attribute indicates that our installation files have a .deploy extension – MyApplication.exe is copied to the deployment server as MyApplication.exe.deploy and is renamed when installed on the client machine. In the deploymentProvider tag we specify where the application can find future updates and from where this application was installed.
The next interesting tag is dependentAssembly, which points to the deployment manifest to use when installing the application on the client machine. We specify the deployment manifest in the codeBase attribute which describes how the application installs. Note that the codebase attribute points to a version folder in which the deployment manifest resides – for every new release of the application this application manifest is either overwritten or updated to point to the new version of the installation files and deployment manifest.
Deployment Manifest
The deployment manifest describes the how the application installs and what files to install on the client. Once again, let’s have a look at the contents:
<?xml version="1.0" encoding="utf-8"?>
<asmv1:assembly xsi:schemaLocation="urn:schemas-microsoft-com:asm.v1 assembly.adaptive.xsd" manifestVersion="1.0" xmlns:asmv3="urn:schemas-microsoft-com:asm.v3" xmlns:dsig="http://www.w3.org/2000/09/xmldsig#" xmlns="urn:schemas-microsoft-com:asm.v2" xmlns:asmv1="urn:schemas-microsoft-com:asm.v1" xmlns:asmv2="urn:schemas-microsoft-com:asm.v2" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:co.v1="urn:schemas-microsoft-com:clickonce.v1">
<asmv1:assemblyIdentity name="App.exe" version="1.0.903.18476" publicKeyToken="0000000000000000" language="neutral" processorArchitecture="msil" type="win32" />
<application />
<entryPoint>
<assemblyIdentity name="App" version="1.0.903.18476" language="neutral" processorArchitecture="msil" />
<commandLine file="App.exe" parameters="" />
</entryPoint>
<trustInfo>
<security>
<applicationRequestMinimum>
<PermissionSet Unrestricted="true" ID="Custom" SameSite="site" />
<defaultAssemblyRequest permissionSetReference="Custom" />
</applicationRequestMinimum>
<requestedPrivileges xmlns="urn:schemas-microsoft-com:asm.v3">
<requestedExecutionLevel level="asInvoker" uiAccess="false" />
</requestedPrivileges>
</security>
</trustInfo>
<dependency>
<dependentOS>
<osVersionInfo>
<os majorVersion="5" minorVersion="1" buildNumber="0" servicePackMajor="0" />
</osVersionInfo>
</dependentOS>
</dependency>
<dependency>
<dependentAssembly dependencyType="preRequisite" allowDelayedBinding="true">
<assemblyIdentity name="Microsoft.Windows.CommonLanguageRuntime" version="2.0.50727.0" />
</dependentAssembly>
</dependency>
<dependency>
<dependentAssembly dependencyType="install" allowDelayedBinding="true" codebase="DevExpress.Data.v9.1.dll" size="855552">
<assemblyIdentity name="App" version="9.1.5.0" publicKeyToken="B88D1754D700E49A" language="neutral" processorArchitecture="msil" />
<hash>
<dsig:Transforms>
<dsig:Transform Algorithm="urn:schemas-microsoft-com:HashTransforms.Identity" />
</dsig:Transforms>
<dsig:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
<dsig:DigestValue>CXehkPHON56TeTj7ZWsy++QsymE=
</hash>
</dependentAssembly>
</dependency>
<file name="GlobalConfiguration.xml" size="21074">
<hash>
<dsig:Transforms>
<dsig:Transform Algorithm="urn:schemas-microsoft-com:HashTransforms.Identity" />
</dsig:Transforms>
<dsig:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
<dsig:DigestValue>6hHtbL9F9sfgWmKLYrWRpYmILCE=
</hash>
</file>
</asmv1:assembly>
The first tag of interest here is the entryPoint tag that identifies the application to run once the installation completes. In order to start the application clickonce will execute the command with the parameters specified in the commandLine tag.
Every application has dependencies that must either be installed with the program or should have been installed. In the first dependency tag we see that the minimum operating system version required is Windows XP. In the second dependency tag we see that the dependencyType attribute instructs clickonce to verify that the .NET Framework 2.0 is already installed on the client.
In the third dependency tag we see that the dependencyType is install, which instructs clickonce to install this dependency on the client. Remember that the .deploy extension will automatically be removed during the installation process.
The next tag is a file tag that specifies a non-assembly file that is copied into the application installation directory. Note: by default when clickonce encounters a xml file it assumes it as a configuration file and will copy it to a data directory; along the application directory; instead of the application directory. You can find the data directory location by querying the System.Deployment.ApplicationApplicationDeployment.DataDirectory property.
In the next installment of this series we will show a build file example and generate a deployment manifest with the Mage tool.
Automating a ClickOnce Deployment – Part1
In our build process, using Team Foundation Build, we decided to use ClickOnce for application deployment. In this post I’ll try to set the lay of the land. In the following couple of posts I will take you through the process of setting up a clickonce deployment.
Choosing the deployment strategy
There are essentially two different ways to deploy clickonce applications. They are:
- Physical media such as CD or DVD
- Network share or web
Deciding on the strategy that will work for you is largely determined by the available bandwidth at the client site. If there is none to very little bandwidth, or no internet connectivity, choose CD / DVD. Otherwise choose Network share or web.
We opted for the web strategy and so I will base the series around this strategy.
Lay of the land
Assume that we have one build server and one deployment server. The build server will push the build artifacts to the deployment server from where clients will use clickonce to install the application. The application is pushed to the deployment server after every build with a new version number.
To make the explanations easier we will setup a hypothetical configuration and base the deployment configuration on it. Our hypothetical solution consists of a single application, which we will call App. Below is a diagram that demonstrates this configuration:
Note: To hide the published share simply name it with a trailing dollar sign i.e. “Published$”.
Initial configuration
First of all we need a folder on the deployment server to push the build artifacts to. For this, create a published folder on the deployment server and share it with modify permissions granted to the TFSSERVICE account. Remember the TFSSERVICE account that TFS uses for the build service?
Furthermore, we need to configure Internet Information Services (IIS) to interpret the clickonce files correctly according to their extension. For this, add the following MIME types in IIS:
.application application/x-ms-application .manifest application/x-ms-manifest .deploy application/octet-stream
If you are using IIS 6.0, have a look at this article “IIS 6.0 Does Not Serve Unknown MIME Types”.
In the next installment I’ll discuss the different files that describe the application and deployment.
XML Intellisense for NHibernate
Using NHibernate requires the writing of some tedious XML-based configuration mapping files. Remembering all the tags and attributes can sometimes be overwhelming. Thankfully the contributors decided to include intellisense hints, which are in nhibernate-configuration.xsd and nhibernate-mapping.xsd.
In order to have the hints available in Visual Studio 2008 copy the files into C:\Program Files\Microsoft Visual Studio 9.0\XML\Schemas and restart Visual Studio.
Rollback Changesets
In Team Foundation Server 2008, there doesn’t seem an easy way to simply perform a rollback on a comitted changeset. Well, that is until you discover the power of the updated Team Foundation Server Power Toys.
Rollback command
Before rolling back a changeset, the local workspace must have no pending changes. After issuing the rollback command, tfpt rollback a dialog will appear asking whether you want the local workspace brought up to date with the repository. After affirming the dialog, a get command will be issued for your workspace and updated with the latest changes.
After the get operation completed successfully, another dialog will appear asking you to identify the changeset that you want to rollback. Note: Make sure that you have the correct changeset before continuing.
Select the files that you want to rollback in the changeset and click on “Roll Back”. After the rollback completed, you might have to resolve some conflicting changes. Now that the rollback is complete, you will still need to commit the new changeset, which is the latest code, without the changeset that was rolled back.
If you want to skip all of the GUI stuff, then you can simply execute the rollback command this way: tfpt rollback /changeset:4018.
AWOL CD-ROM
For the second time now I have had the CD-ROM drive on my HP nw8440 disappear from Windows. The Device Manager reports the following for the CD-ROM drive: “Windows cannot load the device driver for this hardware. The driver may be corrupted or missing. (Code 39)”. Why? It was perfect yesterday and today it is missing or corrupted? Weird. According to the Microsoft Knowledge Base article it can happen after removing a CD or DVD burning program.
Although the error is rather annoying, there is a simple fix for it. I have replicated the steps here for your convenience:
Step 1: Start Registry Editor
Start Registry Editor.
Step 2: Delete the UpperFilters registry entry
- In Registry Editor, expand My Computer, and then expand HKEY_LOCAL_MACHINE.
- Expand SYSTEM, and then expand CurrentControlSet.
- Expand Control, and then expand Class.
- Under Class, click {4D36E965-E325-11CE-BFC1-08002BE10318}.
- In the details pane of Registry Editor, on the right side, click UpperFilters.Note You may also see an UpperFilters.bak registry entry. You do not have to remove that entry. Click UpperFilters only.
- If you see the UpperFilters registry entry in the details pane of Registry Editor, go to step 6.
- If you do not see the UpperFilters registry entry, you still might have to remove the LowerFilters registry entry. To do this, go to “Step 3: Delete the LowerFilters registry entry.”
- On the Edit menu, click Delete.
- Click Yes when you receive the following message:
The UpperFilters registry entry is removed.
Step 3: Delete the LowerFilters registry entry
- In the details pane of Registry Editor, on the right side, click LowerFilters.Note You might see a LowerFilters.bak registry entry. You do not have to remove that entry. Click LowerFilters only.
If you do not see the LowerFilters registry entry, unfortunately this content is unable to help you any more. Go to the “Next Steps” section for information about how you can find more solutions or more help on the Microsoft Web site.
- On the Edit menu, click Delete.
- Click Yes when you receive the following message:
The LowerFilters registry entry is removed.
- Exit Registry Editor.
The article recomends restarting the computer after deleting the two registry entries, but I have found that it works fine without restarting.
Customising Work Item Templates
Making use of either Team System Web Access or Team Explorer you might find it necessary to edit some of the work item templates. At first it might seem very confusing but is quite straight forward.
When editing work item templates there are two tools that you need to know about, witimport and witexport. They are used to import and export specific work item templates from an existing Team Foundation Server project.
First, you need to export the bug work item template by using the following command line:
witexport /f <work item templates folder>
/t <tfs server>:8080 /p <project name> /n bug
This will create a bug.xml template file in the work item templates folder specified, which could be any folder that you have access to.
The first part of the XML file defines the fields (indicated by the fields tag) that describe the bug. A workflow process (indicated by the workflow tag) is described in the middle of the file and the bottom part of the file describes the layout (indicated by the form tag) of the bug submission form.
Let’s add an environment field to the template that will indicate the environment where the bug occurred with the following values, tip, pre-stage, stage and live:
<field name="Environment" refname="TfsProject.Environment" type="String"> <required /> <helptext>Was the bug found in tip, pre-stage, stage or live?</helptext> <allowedvalues> <listitem value="Tip"/> <listitem value="Pre-stage"/> <listitem value="Stage"/> <listitem value="Live"/> </allowedvalues> <default from="value" value="Pre-Stage"/> </field>
The above piece of XML can be put anywhere after a closing field tag or the opening fields tag and must be somewhere before the workflow opening tag.
Name is obviously the name of the field that we are giving the additional piece of information. RefName is the name of this field that we are going to use to refer to when setting up the control in the layout section of the file. The presence of required tag says that a value must be specified for this field and will be validated automatically when a new bug is submitted. Next, we supply a list of values that will appear in the drop down list. Finally we provide a default value that will automatically be selected for each bug submission.
We now have to specify the new look of the form with our additional field and is done with the following XML definition:
<group>
<column PercentWidth="50">
<control Type="FieldControl" FieldName="TfsProject.Environment" Label="&Environment:" LabelPosition="Left" />
</column>
<column PercentWidth="50">
...
</column>
</group>
A group defines a collection of controls that are related. The column tag has an attribute that states the percentage space that the control should occupy. Each group should add up to to 100% but do not have to. The fieldname should be set to the field that we have just created in the fields section of the template. The label attribute is set to the label that we want to show in front of the control. In this case it is “Environment:”.
After placing the control, all that is left is to save the bug.xml file and import it back into Team Foundation Server. This is accomplished by the following command line:
witimport /f <work item templates folder>\bug.xml
/t <tfs server>:8080 /p <project name>
After a successful import the changes should be visible from both TSWA (Team System Web Access) and Team explorer, by double clicking on the Bug work item template.
Go customise those work item templates!
leave a comment