<Reference Include="DocumentFormat.OpenXml, Version=2.5.5631.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL">Setting <Private>True</Private> ensures that the reference is copied to the output folder, looks like setting it to Copy Local, just doesn't do the trick
<SpecificVersion>False</SpecificVersion>
<Private>True</Private> <HintPath>..\..\..\OpenXml SDK 2.5\DocumentFormat.OpenXml.dll</HintPath>
</Reference>
Friday, 29 August 2014
TIL - Copy References in GAC to output folder
A while back I had this problem, looks like there is a simple solution:
Thursday, 21 August 2014
TIL - DeploymentItem files not copied in MSTest
I have a set of unit tests that need an xml file to work and I despite me using the DeploymentItem attribute the test was not working.
Turns out that DeploymentItem will only copy from the build directory, so I set the Copy to Output Directory property of the file to Copy always:
Turns out that DeploymentItem will only copy from the build directory, so I set the Copy to Output Directory property of the file to Copy always:
Monday, 18 August 2014
Product Versions in MSI installers created with WIX - part 1
I must confess that in the past I used to do this manually or not at all (loud gasps) as I've never had a fully functioning CI environment but, this has changed recently so here it goes.
In essence the challenge is to change the version number of the installer every time a new build is done, so that the build number is reflected in both Windows (Control Panel -> Programs and Features ) and the file itself, e.g. installer.1.0.0.0.msi
There are two main ways of doing this, that I know of:
- Pass the build number to the Wix Installer.
- Get the build number from a library or executable.
In this post, I will discuss the first way, all changes unless stated are made to the wix project file (wixproj extension), so you will need to unload the project from Visual Studio or use another editor to make these changes.
We need a Property to hold the version number, which appropriately is called VersionNumber, I've made sure that this is populated with a default value, in case the build is done from Visual Studio.
<VersionNumber Condition=" '$(VersionNumber)' == '' ">0.0.0.0</VersionNumber>I then appended the version number to the installer:
<OutputName>Installer.$(VersionNumber)</OutputName>
We then need to add a preprocessor variable to each build configuration, I've called it MSIVersion, as this is the version of the msi package:
<DefineConstants>MSIVersion=$(VersionNumber)</DefineConstants>and finally we use this preprocessor variable in the product definition in the Product.wxs file.
<Product Id="01010101-deaf-beef-c0de-863f442f44fb" Name="MROAE" Language="1033" Version="$(var.MSIVersion)" Manufacturer="MROAE" UpgradeCode="01010101-daaa-beef-c0de-863f442f44fb">
This solution can now be build with the following command:
msbuild mysolution.sln /p:VersionNumber=1.0.0.1A sample wixproj file can be found below with changes detailed above:
<?xml version="1.0" encoding="utf-8"?> <Project ToolsVersion="4.0" DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003"> <PropertyGroup> <Configuration Condition=" '$(Configuration)' == '' ">Debug</Configuration> <Platform Condition=" '$(Platform)' == '' ">x86</Platform> <PackageVersion>3.8</PackageVersion> <ProjectGuid>{02af16dd-0000-0000-0000-d60ba5af40cc}</ProjectGuid> <SchemaVersion>2.0</SchemaVersion> <OutputType>Package</OutputType> <WixTargetsPath Condition=" '$(WixTargetsPath)' == '' AND '$(MSBuildExtensionsPath32)' != '' ">$(MSBuildExtensionsPath32)\Microsoft\WiX\v3.x\Wix.targets</WixTargetsPath> <WixTargetsPath Condition=" '$(WixTargetsPath)' == '' ">$(MSBuildExtensionsPath)\Microsoft\WiX\v3.x\Wix.targets</WixTargetsPath> <VersionNumber Condition=" '$(VersionNumber)' == '' ">0.0.0.0</VersionNumber> <Name>Installer</Name> <OutputName>Installer.$(VersionNumber)</OutputName> </PropertyGroup> <PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|x86' "> <OutputPath>bin\$(Configuration)\</OutputPath> <IntermediateOutputPath>obj\$(Configuration)\</IntermediateOutputPath> <DefineConstants>Debug;MSIVersion=$(VersionNumber)</DefineConstants> </PropertyGroup> <PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|x86' "> <OutputPath>bin\$(Configuration)\</OutputPath> <IntermediateOutputPath>obj\$(Configuration)\</IntermediateOutputPath> <DefineConstants>MSIVersion=$(VersionNumber)</DefineConstants> </PropertyGroup> <ItemGroup> <Compile Include="Service.wxs" /> <Compile Include="Product.wxs" /> </ItemGroup> <ItemGroup> <ProjectReference Include="..\Service\Service.csproj"> <Name>Service</Name> <Project>{000c956c-0000-0000-0000-970884f34476}</Project> <Private>True</Private> <DoNotHarvest>True</DoNotHarvest> <RefProjectOutputGroups>Binaries;Content;Satellites</RefProjectOutputGroups> <RefTargetDir>INSTALLFOLDER</RefTargetDir> </ProjectReference> </ItemGroup> <ItemGroup> <Content Include="Icons\Product.ico" /> </ItemGroup> <ItemGroup> <Folder Include="Icons" /> </ItemGroup> <ItemGroup> <WixExtension Include="WixUtilExtension"> <HintPath>$(WixExtDir)\WixUtilExtension.dll</HintPath> <Name>WixUtilExtension</Name> </WixExtension> </ItemGroup> <Import Project="$(WixTargetsPath)" /> <!-- To modify your build process, add your task inside one of the targets below and uncomment it. Other similar extension points exist, see Wix.targets. <Target Name="BeforeBuild"> </Target> <Target Name="AfterBuild"> </Target> --> </Project>
And the Product File(product.wxs)
<Product Id="01010101-deaf-beef-c0de-8f3f4a2f44fb" Name="MROAE" Language="1033" Version="$(var.MSIVersion)" Manufacturer="MROAE" UpgradeCode="01010101-daaa-beef-c0de-8f3f4a42f44b">
Monday, 11 August 2014
Uninstall MSI from command line
From a command prompt, run with elevated permissions:
msiexec /x {ba5eba11-deaf-beef-ce11-ca5e1337c0de} /qnwhere {ba5eba11-deaf-beef-ce11-ca5e1337c0de} is the product code of the application you want to uninstall.
From PowerShell, run with elevated permissions:
msiexec /x "{ba5eba11-deaf-beef-ce11-ca5e1337c0de}" /qnIf you don't know the product code you can get it from the registry, using wmic or from PowerShell using the following command:
gwmi -Class win32_product | ?{$_.Name -match "product name"}For 7-zip the product code is:
PS C:\Users\Bob> gwmi -Class win32_product | ?{$_.Name -match "7-zip"}
IdentifyingNumber : {23170F69-40C1-2702-0920-000001000000}
Name : 7-Zip 9.20 (x64 edition)
Vendor : Igor Pavlov
Version : 9.20.00.0
Caption : 7-Zip 9.20 (x64 edition)
Wednesday, 6 August 2014
TIL - Send CTRL + ALT + DEL to Remote Destop Connection
I needed to change my password on the test domain today but I only log on to the test domain through a remote desktop connection, so in order to do a CTRL + ALT + DEL on the remote desktop, I did:
Monday, 4 August 2014
List Entity relationships in CRM 2011/2013 - Brain Dump 6
Cleaning up my inbox today when I found this SQL query, in short a quick way of listing all the relationships for a particular entity:
And the results:
SELECT distinct (rel.name),ent.name, Case [CascadeDelete] when 0 then 'None' when 1 then 'All' when 2 then 'Referential' when 3 then 'Restrict' end as CascadeDelete ,Case [CascadeAssign] when 0 then 'None' when 1 then 'All' when 2 then 'Referential' when 3 then 'Restrict' end as CascadeAssign ,Case [CascadeShare] when 0 then 'None' when 1 then 'All' when 2 then 'Referential' when 3 then 'Restrict' end as CascadeShare ,Case [CascadeUnShare] when 0 then 'None' when 1 then 'All' when 2 then 'Referential' when 3 then 'Restrict' end as CascadeUnShare ,Case [CascadeReparent] when 0 then 'None' when 1 then 'All' when 2 then 'Referential' when 3 then 'Restrict' end as CascadeReparent ,Case [CascadeMerge] when 0 then 'None' when 1 then 'All' when 2 then 'Referential' when 3 then 'Restrict' end as CascadeMerge from MetadataSchema.Relationship rel join MetadataSchema.Entity ent on rel.ReferencedEntityId = ent.entityid where rel.name like '%<entityname>%' order by ent.Name
Subscribe to:
Posts (Atom)