2

I was successful to have this working locally:

<Target Name="InitializeSourceControlInformation" />
<UsingTask TaskName="GetAssemblyVersion" AssemblyFile="$(MSBuildSDKsPath)\Microsoft.NET.Sdk\tools\net46\Microsoft.NET.Build.Tasks.dll" />
<Import Project="$(MSBuildSDKsPath)\Microsoft.NET.Sdk\build\Microsoft.NET.GenerateAssemblyInfo.targets" />

But it fails on the CI server, which only has the VS 2017 BuiltTools. And in general it feels hacky and fragile.

But, I still want to use these targets because they are great. Is there a robust way to use them? They do not seem to depend on anything else in the Sdk realm, except one custom task.

EDIT 1

Our build servers indeed have VS 2017 Build Tools. But the developers all have VS 2017 and VS 2015. The latter is needed if a Silverlight bug has to be fixed. Yes, we still have Silverlight.

P.S.

Please, do not suggest to migrate to .NET Core. I would migrate to the Sdk style project, but there is another question for that - Is it possible to write VS extensions using the SDK style projects?

mark
  • 59,016
  • 79
  • 296
  • 580

1 Answers1

2

I actually created an MSBuild Sdk for that so the same logic can be used for classic projects (classic asp.net, .net framework WPF apps and so on): https://github.com/dasMulli/AssemblyInfoGenerationSdk. Maybe this is what you need. Do open issues if it doesn't work for you.

This works by copying some of the (MIT open source) code from the .NET SDK and packing it into an MSBuild SDK.

Martin Ullrich
  • 94,744
  • 25
  • 252
  • 217
  • Could you provide instructions on how to use it? Should I copy some files from your repo over to our code base? Could you provide a little bit more details? – mark Nov 21 '19 at 05:55
  • So I need to download these targets first and just embed in my source code? Honestly I would rather have a way to import the standard sdk targets. Or have a nuget package. – mark Nov 21 '19 at 15:53
  • No, add the `` attribute to classic projects as described to get the logic via the NuGet package. If you want to build something like that yourself, you can use the project files as a starting point. But my goal was that you add the one line and classic projects will behave the same as .net core projects in regard to assembly info generation. – Martin Ullrich Nov 21 '19 at 16:49
  • Oh, I did not realize the Sdk element invokes nuget to automatically fetch the SDK. Amazing. – mark Nov 21 '19 at 18:26
  • Alas, we still have to support VS 2015 - no `` attribute for me. That is why I wanted to get the functionality by reusing the respective Sdk scripts, but in the old way. – mark Nov 22 '19 at 05:56
  • Oh, the question mentioned 2017. You can still download and extract the nupkg and import the full path to the sdk.props and sdk.targets files in the beginning and at the end (respectively) of your csproj files. – Martin Ullrich Nov 22 '19 at 08:50
  • The point is that they also require a task assembly accessing some NuGet logic to work with version numbers. – Martin Ullrich Nov 22 '19 at 08:50
  • I added **EDIT 1**. It is very unfortunate and I suppress it almost subconsciously to recall later. – mark Nov 22 '19 at 12:57
  • We can assume the SDK is installed along with the tasks and targets, because all have either VS 2017 build tools or the actual IDE. But I cannot use the sdk syntax, because of the need to support VS 2015. – mark Nov 23 '19 at 00:47
  • We got rid of Silverlight completely 6 months ago. – mark Jan 14 '22 at 18:26
  • Could you have a look at https://stackoverflow.com/questions/70715436/without-developing-own-sdk-is-there-a-way-to-use-sdk-style-projects-for-code-us ? Thank you. – mark Jan 14 '22 at 19:07