I am using TeamCity for a continuous integration server and am deploying my application using a ClickOnce installer. I can get the installer to function and deploy my application but I cannot figure out how to include the installer for .net 4.5 if the computer does not already have it installed or how to enable the auto-update check feature in ClickOnce deployments. I am currently using the MSBuild file below to build my installer
<Project DefaultTargets="DoPublish" ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<Import Project="$(MSBuildExtensionsPath)\MSBuildCommunityTasks\MSBuild.Community.Tasks.Targets"/>
<PropertyGroup>
<Version>$(BUILD_NUMBER)</Version>
<Install>true</Install>
<InstallFrom>Unc</InstallFrom>
<UpdateEnabled>true</UpdateEnabled>
<UpdateMode>Background</UpdateMode>
<ClickOnceBuildDirectory>$(MSBuildProjectDirectory)\MyProject\bin\$(Configuration)\app.publish</ClickOnceBuildDirectory>
<ClickOnceInstallDirectory>$(MSBuildProjectDirectory)\Publish</ClickOnceInstallDirectory>
<ClickOnceFinalLocation>$(env_PublishUrl)</ClickOnceFinalLocation>
</PropertyGroup>
<Target Name="DoPublish">
<RemoveDir Directories="$(ClickOnceInstallDirectory)" ContinueOnError="true" />
<MSBuild Projects="MyProject.sln" Targets="Clean;Build" Properties="ApplicationVersion=$(Version);Configuration=$(Configuration)"/>
<MSBuild Projects="MyProject\MyProject.csproj" Targets="Publish" Properties="ApplicationVersion=$(Version);Configuration=$(Configuration);InstallUrl=$(ClickOnceFinalLocation)" />
<MakeDir Directories="$(ClickOnceInstallDirectory)"/>
<Exec Command="xcopy /E $(ClickOnceBuildDirectory) $(ClickOnceInstallDirectory)" />
</Target>
</Project>
You can use a bootstrapper to handle prerequisites like checking for the .NET Framework. Check the Application Deployment Prerequisites MSDN article, especially the sections about bootstrapping with ClickOnce and MSBuild.
There are also 2 more MSDN articles that detail how to install ClickOnce prerequisites and Creating bootstrapper packages.
As for auto-updates, do you want to locate the auto-update functionality outside the application itself, i.e., in an installer vs. in the application? There are several ways to allow ClickOnce updates in your application, including auto-updates via the ClickOnce Deployment API.
A brief explanation of using ClickOnce Bootstrapper packages can be found in this existing Stackoverflow article. Though you're not using WiX here, you can also check this this WiX thread, which is useful because you see some of the steps that didn't work along the way. These examples show the use of the GenerateBootstrapper MSBuild task to create the bootstrapper for the ClickOnce installer. Note that in the examples at the above links, the "Path" in the GenerateBootstrapper task is set to a subfolder under a Windows SDK location. This can be changed to another location, as long as that location has the necessary prerequisite packages.
Below is an example in which the .NET 4.5 Framework is set as a prerequisite for the install. The parent directory structure for the .NET 4.5 prerequisite is specified by the $(MyPathToPrerequisitePackages) property.
The BootstrapperFile item in the below example specifies the .NET 4.5 Framework prerequisite package. The value ".NETFramework,Version=v4.5" comes from the product.xml file in the Bootstrapper\Packages\DotNetFX45 folder, and allows the GenerateBootstrapper task to correctly identify the .NET 4.5 prerequisite/bootstrapper package. The "ProductName" value is simply a friendly description of the package.
<PropertyGroup>
<MyPathToPrerequisitePackages>C:\Program Files (x86)\Microsoft SDKs\Windows\v8.0A\Bootstrapper</MyPathToPrerequisitePackages>
</PropertyGroup>
<ItemGroup>
<BootstrapperFile Include=".NETFramework,Version=v4.5">
<ProductName>.NET Framework 4.5</ProductName>
</BootstrapperFile>
</ItemGroup>
<GenerateBootstrapper
ApplicationFile="$(MyAppAssembly).application"
ApplicationUrl="$(MyClickOnceAppUrl)"
ApplicationName="$(MyClickOnceAppName)"
BootstrapperItems="#(BootstrapperFile)"
Culture="en"
FallbackCulture="en-US"
CopyComponents="true"
Validate="false"
Path="$(MyPathToPrerequisitePackages)"
SupportUrl="$(MyAppSupportUrl)"
OutputPath="$(MyDesiredOutputPath)\" />
Just posted a response on 'https://stackoverflow.com/a/39610060/1345870':
Just struggled with this myself - I chose to commit the bootstrapper files to source control. It is possible to override the path to bootstrappers, just provide /p:GenerateBootstrapperSdkPath=.build\Bootstrapper
Then no need to modify registry - and the added benefit that the build is now self-contained.
Only "problem" is that I have to manually copy the Bootstrapper files into source control. In my case (VStudio2015), this meant copying the files from C:\Program Files (x86)\Microsoft Visual Studio 14.0\SDK\Bootstrapper
Related
When I use Visual Studio for Mac to create a web project with .Net core 1.1, there is no project.json in my project. Is there any mistake when I create
this project?
Project.json was never released in production. It was replaced by a new, vastly simplified MSBuild project format before .NET Core was released. The new format works a lot like the project.json format - it supports globbing, package references and compiles all *.cs* files found in a folder. You don't need to define dependent packages in the project file any more, you can specify *one* root package and all dependencies will be added when you executedotnet restore`
.NET Core allows you to add commandlets that appear as commands to the .NET CLI. dotnet watch executes the dotnet-watch executable. dotnet ef searches for and executes the dotnet-ef executable.
You have to add an option to the MSBuild project that installs the tool in the first place with the <DotNetCliToolReference> element. After that, dotnet restore will install the tool just like any other package.
This is described in .NET Core Command Line Tools for EF Core.
The MSBuild project file should look like this :
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<OutputType>Exe</OutputType>
<TargetFramework>netcoreapp2.0</TargetFramework>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="Microsoft.EntityFrameworkCore.Design" Version="2.0.0" PrivateAssets="All" />
</ItemGroup>
<ItemGroup>
<DotNetCliToolReference Include="Microsoft.EntityFrameworkCore.Tools.DotNet" Version="2.0.0" />
</ItemGroup>
</Project>
This file is enough to build your project and execute ef commands from the command line, since all *.cs files will be compiled by default
project.json is deprecated and was never supported outside preview .NET Core tooling in VS 2015. The new tooling uses csproj files and can be used in VS 2017 and VS for Mac (and others like VSCode, Rider, …).
The Visual Studio Setup and Deployment uses Prerequisites.
These Prerequisites come as Bootstrapper packages with preconfigured Product.xml and Package.xml.
Can I reuse these configuration XML or do I need to redo the configuration when I making a PackageGroup for WiX?
The SQLExpress2008R2 Bootstrapper package:
product.xml: Contains related products and calls a SQLExpressCheck.exe
package.xml: Decides on the Architecture and has default arguments for installing the SQL Server
If I cannot reuse the Product.xml and Package.xml in Burn, should I resort to the BootstrapperFile in the WixProj file?
Unfortunately, you have to create your own PackageGroups and ExePackages. While some information can be copied from the Visual Studio Bootstrapper packages, you should look for the installation documentation for the prerequisite. Sometimes the real installation instructions are hidden in the release notes or even MSDN blogs. You might have to Google for "silent" or "unattended".
It wouldn't do any good to add GenerateBootstrapper to the .wixproj file because .wixproj files are not designed to import the common microsoft targets.
I decided in my case to instead of writing Burn PackageGroups use the following setup in the wixproj.
I have 7 Bootstrapper Packages with complex product.xml and package.xml and it would have made no sense to recreate Burn Package Groups.
<ItemGroup>
<BootstrapperFile Include=".NETFramework,Version=v4.0">
<ProductName>Microsoft .NET Framework 4 (x86 und x64)</ProductName>
</BootstrapperFile>
</ItemGroup>
<PropertyGroup>
<WindowsSDKBootstrapperPath>$(registry:HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\GenericBootstrapper\4.0#Path)</WindowsSDKBootstrapperPath>
</PropertyGroup>
<Target Name="BeforeBuild">
</Target>
<Target Name="AfterBuild">
<GenerateBootstrapper ApplicationFile="$(TargetFileName)" ApplicationName="Rodenstock Consulting" ApplicationRequiresElevation="True" BootstrapperItems="#(BootstrapperFile)" ComponentsLocation="Relative" CopyComponents="True" OutputPath="$(OutputPath)" Path="$(WindowsSDKBootstrapperPath)" />
</Target>
i've inherited a setup project which uses Wix 3.0
For programming reason we must switch to VS2012 and therefore to Wix 3.7, too.
While reading about Wix 3.7 i found out that 3.7 offers project type "Setup project"
and project type "Bootstrapper project".
My first question is: Have i to make a Setup project as before AND a bootstrapper project and combine it or just a bootstrapper project.
Using Wix 3.0 the bootstrapper stuff was located in the wixproj file:
<ItemGroup>
<BootstrapperFile Include="Microsoft.Net.Framework.3.5.SP1">
<ProductName>Microsoft .NET Framework 3.5 SP1</ProductName>
</BootstrapperFile>
<BootstrapperFile Include="Microsoft.Windows.Installer.3.1">
<ProductName>Windows Installer 3.1</ProductName>
</BootstrapperFile>
</ItemGroup>
<Target Name="AfterBuild">
<GenerateBootstrapper Condition=" '$(Platform)' == 'x86' " ApplicationName="$(ProductName)" BootstrapperItems="#(BootstrapperFile)" ComponentsLocation="HomeSite" CopyComponents="True" OutputPath="$(TargetDir)%(CultureGroup.OutputFolder)" Culture="%(CultureGroup.Identity)" FallbackCulture="en-us" Path="$(WindowsSDKPath)" />
<GenerateBootstrapper Condition=" '$(Platform)' == 'x64' " ApplicationName="$(ProductName) (x64)" BootstrapperItems="#(BootstrapperFile)" ComponentsLocation="HomeSite" CopyComponents="True" OutputPath="$(TargetDir)%(CultureGroup.OutputFolder)" Culture="%(CultureGroup.Identity)" FallbackCulture="en-us" Path="$(WindowsSDKPath)" />
</Target>
Is this still possible? Here i have to change from .Net 3.5SP1 to .Net 4.5
Can somebody help me?
First, you could upgrade by just using WiX Toolset 3.7 and running wixcop on your WiX files to upgrade them.
If you want to use the new WiX bootstrapper...
You need both project types. A "Setup" project creates an .msi file. A "Bootstrapper" project creates an .exe file.
Remove the Visual Studio Bootstrapper items and GenerateBootstrapper tasks from your setup project. Create corresponding ExePackage or PackageGroupRef elements in your bootstrapper's Chain. A PackageGroup roughly corresponds to a Visual Studio Bootstrapper package but the "syntax" is different. To recreate a Visual Studio Bootstrapper package consult the files under C:\Program Files (x86)\Microsoft Visual Studio 8\SDK\v2.0\Bootstrapper\Packages or equivalent.
For the Microsoft .NET framework, the WixNetfxExtension extension defines package groups that you can just reference.
I've managed to get builds working on my build server, but now the issue I have is that the output in the output folder contains all output from all projects, rather than just the output from the wix project(s).
Any idea how to change this?
TIA
If you are only interested in the msi as a build output then you could create a step in your team build to copy your installer files to another location, the following build target, added to your build project should help.
This overrides the target AfterDropBuild
<Target Name="AfterDropBuild">
<PropertyGroup>
<InstallerDir>$(DropLocation)\$(BuildNumber)\Installers</InstallerDir>
</PropertyGroup>
<Message Importance="low" Text="InstallerDir=$(InstallerDir)" />
<MakeDir Directories="$(InstallerDir)" Condition="!Exists('$(InstallerDir)')" />
<CreateItem Include="$(BinariesRoot)\**\*.msi">
<Output TaskParameter="Include" ItemName="InstallationFiles"/>
</CreateItem>
<Copy SourceFiles="#(InstallationFiles)"
DestinationFolder="$(InstallerDir)"/>
</Target>
I create different solution platforms { Application, Setup } and set my .NET projects to build with application and my wix to build with setup. Then I tell the build definition to build those two platforms in that order. The result is that TFS archives the .NET code in an application folder that looks like the deployed machine and the MSI in the setup folder.
Only downside is when you add new projects you have to select the platform to build in configuration manager. My developers don't seem annoyed by it though.
I am using team city to call a nant script, currently this nant script is very simplistic and only calls an msbuild task on a single project in the solution.
The build is failing, it looks like msbuild 3.5 is being called, but it is incorrectly calling the csc.exe from the .net 2.0 folder. Since we are using .net 3.5 language features the compilation fails.
Looking at the csproj file, both the ToolsVersion and TargetFrameworkVersion are both set to use 3.5. What would be causing msbuild to pick the wrong version of csc.exe?
MSBuild uses a Toolset of tasks, targets, and tools to build an application. Typically, a MSBuild Toolset includes a microsoft.common.tasks file, a microsoft.common.targets file, and compilers such as csc.exe and vbc.exe. To ensure MSBuild invokes the correct C# compiler (csc.exe), specify the Toolset in the ToolsVersion attribute on the Project element in the project file.
The following example specifies that the project should be built by using the MSBuild 4.0 Toolset.
<Project ToolsVersion="4.0" ... </Project>
More information pertaining to the ToolsVersion attribute can be found here:
http://msdn.microsoft.com/en-us/library/78f4aasd.aspx
Do you have the 2.0 version of csc directly in your path, perhaps?
What happens when you run msbuild from a Visual Studio 2008 Command Prompt?
You can directly point which msbuild you want to use in nant script by declaring:
<!-- Initial path to use MSBuild from .NET Framework 3.5 -->
<property name="MSBuildApp" value="C:\WINDOWS\Microsoft.NET\Framework\v3.5\MSBuild.exe" />
And then execute build via msbuild:
<exec failonerror="true" program="${MSBuildApp}" verbose="true">
<arg value="${SlnDir}\${SlnFile}" />
<arg value="/t:Rebuild" />
<arg value="/p:Configuration=${SlnConfig}" />
</exec>
Or you can point to proper .NET framework version when running NANT script:
nant CreateYouProjectTask -t:net-3.5 -buildfile:BuildYourProject.build