How do you set AssemblyVersion when using Publish Profiles (.pubxml) from a Web Site Project?
Asked Answered
G

3

5

I am using the new ASP.Net and Web Tools 2012.2 Publish Profiles for Web Sites (not web application).

I have created a Publish Profile using the tooling which has created the file website.publishproj in the root of the web site.

The website.publishproj file contains the following:

<AssemblyAttributes Include="AssemblyFileVersion">
    <Value>$(AssemblyFileVersion)</Value>
</AssemblyAttributes>
<AssemblyAttributes Include="AssemblyVersion">
    <Value>$(AssemblyVersion)</Value>
</AssemblyAttributes>

This would suggest that you can pass in the properties to MSBuild to set the version of the output dll.

However, single output assembly for the website (it is compiled and then merged into a single assembly) always has the version number 1.0.0.0.

I have tried passing in /p:AssemblyFileVersion=2.1.0.0;AssemblyVersion=2.1.0.0 but this has no effect.

I've even tried editing the website.publishproj file directly, but this has no effect either.

Does anyone know how to set the version number of the output assembly on a Web Site Project when you want it merged into a single assembly?

Goldshell answered 28/2, 2013 at 22:38 Comment(0)
G
6

I've managed to solve this issue. I think it is a bug with the tools.

If you set the OutputPath property to a relative path in the website.publishproj file, then the AssemblyVersion and AssemblyFileVersion properties are not respected.

This is due to how this versioning works when merging website assemblies into one single assembly.

What happens is that an AssemblyInfo.cs file is generated during the deploy and the supplied version numbers are inputted. This AssemblyInfo.cs file is then compiled into an AssemblyInfo.dll containing the version numbers you passed in.

Then aspnet_merge.exe is called with the copyattrs argument pointing to the AssemblyInfo.dll it generated previously.

If you set OutputPath to a relative path then this copyattrs argument points to a dll that does not exist. This is because it is run from the path where the aspnet_merge.exe tool lives. Therefore a relative path back to the AssemblyInfo.dll assembly does not find it's true location.

OutputPath cannot be relative.

To fix the issue, I set mine to:

<PropertyGroup>
    <OutputPath>$(MSBuildProjectDirectory)\..\..\TempPackageBuildDir\</OutputPath>
</PropertyGroup>

Why bother setting the OutputPath at all?

When you do not set the OutputPath it uses the temp directory in your environment variables. In my case, this would cause the build to fail, because the file lengths of some of the files were exceeding the 260 character windows limit (I have a very large website). The only way I could get it to build at all was to set the OutputPath to a more shallow path.

Goldshell answered 1/3, 2013 at 8:21 Comment(1)
I was able to edit the version directly in the website.publishproj file in the <AssemblyFileVersion> and <AssemblyVersion> elements in a previous <PropertyGroup> element block. Maybe this is new functionality after this question was asked and answered. Or a bug was fixed. Either way. Hope this helps someone else.Tove
K
2

For me the solution was to add the attributes to my .pubxml file.

<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <PropertyGroup>
    <AssemblyVersion>2.3.0.0</AssemblyVersion>
    <AssemblyFileVersion>2.3.0.0</AssemblyFileVersion>
    ... rest of properties ...
  </PropertyGroup>
</Project>
Kulak answered 16/10, 2020 at 16:58 Comment(0)
D
0

I was getting a similar issue, but for a different reason.

My project's MSBuild Options > Output folder path was set to a different path than my Publish > Connection > Target location path, and so it wasn't inheriting the version information from the AssemblyInfo.dll

Hopefully this will help someone else.

Denominational answered 2/7, 2014 at 22:57 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.