-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Bump tasks assembly and file versions automatically with every nightly build #488
Comments
@mavasani your recent PR (that was rolled back) did this right? Can we resurrect just that part of it? Without this when users upgrade to RC3, if they have the old msbuild instance running, there could be weirdness. |
@srivatsn That commit caused Microbuild failure with the below MSBuild error:
This passed fine locally if I set BUILD_BUILDNUMBER, which forces this invocation and also generates correct build numbers. I tried both on a machine with just Dev14 as well as one with just Dev15 and locally it works fine. We use the exact same syntax in Roslyn too and it works fine: https://github.com/dotnet/roslyn/blob/master/build/Targets/Versions.props#L43. @srivatsn you know if there is anything special about the microbuild machine for SDK repo? @rainersigwald you have any suggestions how to address this failure? |
So, I identified that my commit above by itself is not sufficient to implement this. Roslyn and Roslyn project system repos have GenerateAssemblyInfo.targets that actually consume these version related properties and generate the assembly info. This targets file is imported in the common Targets file (https://github.com/dotnet/roslyn/blob/e509b57971474c4d5937bb9a7434839ee8e2c31b/build/Targets/Imports.targets#L332) that is imported by every project in the repo. SDK repo on the other hand doesn't have concept of such a common Targets that is imported by every single project (it just has a Common.Props). We will first need to create such a common Imports.Targets, make sure every project imports it, and then import GenerateAssemblyInfo.targets in this targets file. |
SDK builds with SDK, which has built in support for this. We disable it because at the time we had a chicken and egg problem with the feature coming online. We can actually just set |
Setting GenerateAssemblyInfo to true for Microsoft.NET.Build.Tasks.csproj gives the following errors:
Additionally, it seems none of the template assemblies generated in the output dir, i.e. Microsoft.VisualStudio.ProjectSystem.XXX.Templates.dll, respect this flag and always have all versions 0.0.0.0. I have pushed all the changes I made locally to https://github.com/mavasani/sdk/blob/BuildVersion/Common.props. @nguerrera I am moving over the bug to you. |
Update the assembly version with every nightly build. Fixes #488.
Currently both are hard-coded to 1.0.0.0.
We keep running in to issues where there is a build-to-build break in the SDK and an msbuild process can't SxS load two SDK task assemblies with the same name.
I think we can bump both with every daily build number. It's a simple fix and since the tasks assembly is not designed to have any exchange types, SxS loading any two different builds should be acceptable.
cc @davkean @rainersigwald @dsplaisted
The text was updated successfully, but these errors were encountered: