Generate AssemblyInfo attributes during build #81

nguerrera · 2016-08-23T16:47:22Z

Fix #57, which covers the generation portion of #2

nguerrera · 2016-08-23T16:48:18Z

src/Tasks/Microsoft.DotNet.Core.Build.Tasks/GetAssemblyVersion.cs

+            NuGetVersion version;
+            if (string.IsNullOrEmpty(SemanticVersion) || !NuGetVersion.TryParseStrict(SemanticVersion, out version))
+            {
+                Log.LogError($"Invalid semantic version: '{SemanticVersion}'");


Looks like this is the first custom error message. Thoughts on localization for this assembly?

#33 tracks adding a resource file. There some (project system?) errors preventing us from using the designer

In reply to: 75905846 [](ancestors = 75905846)

OK, I'll add a TODO with reference to #33.

What errors?

In this case, $(Version) does not parse as a semantic version.

Oh, you mean the errors preventing loc. #33 has some details.

davkean · 2016-08-23T17:15:29Z

👍 This looks great.

davkean · 2016-08-23T17:17:47Z

tag @dotnet/project-system

eerhardt · 2016-08-23T17:30:20Z

...sks/Microsoft.DotNet.Core.Build.Tasks/build/netstandard1.0/Microsoft.DotNet.Core.Sdk.targets

@@ -130,6 +131,105 @@ Copyright (c) .NET Foundation. All rights reserved.
    </ItemGroup>
  </Target>

+  <!--
+    ============================================================
+                                     GenerateAssemblyInfo


Do you think it would be worthwhile to split this into its own .targets file?

My thoughts are twofold:

It organizes the logic well. Someone can easily see a file named "Microsoft.NETCore.GenerateAssemblyInfo.targets" and quickly understand what logic is in that file.

It allows us to reuse this logic in other .targets files without importing the whole "Sdk.targets" file.

I'd be fine with that. I'll do it unless someone pushes back.

Only downside I can think of is that it makes it easier to accidentally double-import, and it makes debugging somewhat more difficult because you have to hop to another file.

I think we've gone way too far in the "put everything in one giant mass of spaghetti" direction historically, so I support separate files for logically separate things.

My thinking has been "if I was coding in C#, would I make a separate class for this logic? If yes, I use a separate file."

👍 for non-giant-mass-of-spaghetti targets

eerhardt · 2016-08-23T17:41:52Z

Looks good, @nguerrera. Just some random comments and thoughts.

when addressed.

nguerrera · 2016-08-23T21:47:43Z

Hmm, WriteCodeFragment is generating superfluous ';'s that break compilation on the non-CodeDom implementation for .NET Core. :( Tests started failing. Lost as to how they passed before. I'm going to submit a PR to msbuild xplat branch, what's the flow to here like?

davkean · 2016-08-23T21:53:52Z

We're (CPS, us, MSBuild) are all inserting into the same branch on the VS side now - so the flow on the VS side is okay. Not sure how we pick up the new MSBuild on the CLI side though, @eerhardt?

rainersigwald · 2016-08-23T21:57:48Z

To update CLI's MSBuild, should be something like dotnet/cli@5f60c2c.

MSBuild's packages aren't auto-published, so you might have to ping us/me if we don't remember to trigger a build after the change is merged.

nguerrera · 2016-08-23T22:17:33Z

dotnet/msbuild#935

eerhardt · 2016-08-23T22:21:26Z

Not sure how we pick up the new MSBuild on the CLI side though, @eerhardt?

First we need to take the new MSBuild drop into the CLI. Searching all project.json files in the CLI for MSBuild packages, and updating the versions.

Then once we have a build of the CLI with the new MSBuild, we change the https://github.com/dotnet/sdk/blob/master/DotnetCLIVersion.txt to the new build of the CLI.

nguerrera · 2016-08-24T16:34:45Z

MSBuild's packages aren't auto-published, so you might have to ping us/me if we don't remember to trigger a build after the change is merged.

@rainersigwald It's merged (thanks for that), please trigger a build.

rainersigwald · 2016-08-24T17:14:07Z

Duplicate comment but it's more relevant here: @nguerrera I built packages at version 0.1.0-preview-00032-160824 with this change.

nguerrera · 2016-08-24T17:15:44Z

First we need to take the new MSBuild drop into the CLI. Searching all project.json files in the CLI for MSBuild packages, and updating the versions.

dotnet/cli#4083

nguerrera · 2016-08-24T19:15:13Z

Then once we have a build of the CLI with the new MSBuild, we change the https://github.com/dotnet/sdk/blob/master/DotnetCLIVersion.txt to the new build of the CLI.

@eerhardt The CLI change is in. When will we get a new build? Is it nightly or is there a manual process?

eerhardt · 2016-08-24T19:20:45Z

When will we get a new build? Is it nightly or is there a manual process?

Neither. The official build is kicked off on each merge into the branch. So the official build is running now. It takes around an hour.

See all the build definitions marked with Dotnet CLI CI XXX [feature-msbuild] https://mseng.visualstudio.com/dotnetcore/_build/explorer

The new build number is generated from the commit count. So your build will be version 1.0.0-featmsbuild-003466, if you want to start preparing a change in dotnet/sdk to consume this new build.

eerhardt · 2016-08-25T22:10:46Z

src/Tasks/Microsoft.NETCore.Build.Tasks/build/netstandard1.0/Microsoft.NETCore.Sdk.targets


  <PropertyGroup>
    <!-- We don't use any of MSBuild's resolution logic for resolving the framework, so just set these two
              properties to any folder that exists to skip the GetReferenceAssemblyPaths task (not target) and
+              properties to any folder that exists to skip the GetReferenceAssemblyPaths task (not target) and


Was this line intentially duped?

Fix #87

Also, use $(AssemblyTitle) defaulted to $(AssemblyName) instead of using $(AssemblyName) directly for AssemblyTitleAttribute Finally, don't set Authors and Copyright in template since $registeredorg$ is often blank and it clutters the new project. Just let users set authors and copyright as they see fit. This seems more in keeping with the spirit of minimal boilerplate in the new .csproj files.

nguerrera · 2016-08-25T22:39:42Z

@eerhardt @davkean, made several updates including template change and basic tests. Mind reviewing again?

@natidea Can you review the template changes?

eerhardt · 2016-08-25T22:51:15Z

I really hope we can figure out getting the daily build into the $(FileVersion) by default, in the future.

nguerrera · 2016-08-25T22:55:15Z

I really hope we can figure out getting the daily build into the $(FileVersion) by default, in the future.

Agreed. FWIW, the exact $(Version) gets in to InformationalVersion and can be seen in explorer properties as "Product Version". So nothing is lost, but we should think about if we're putting the right numbers in the right field...

Conflicts: src/Tasks/Microsoft.NETCore.Build.Tasks/Microsoft.NETCore.Build.Tasks.csproj

kzu · 2016-09-08T11:37:41Z

I think this should be moved to the Microsoft/MSBuild repo common targets.

eerhardt · 2016-09-08T14:06:56Z

I think this should be moved to the Microsoft/MSBuild repo common targets.

I would like to see some sort of decent line drawn between what is "MSBuild" functionality, and what is outside of MSBuild in the language/platform's "SDK". Currently that line is super blurry, if it exists at all. Technically, if something is ".NET project specific", it shouldn't really be a part of MSBuild since MSBuild can be used to build things that aren't .NET (like C++ projects).

The point of this repo, IMO, is to become the SDK for .NET projects. That way .NET can innovate its projects without having to ship a new MSBuild, or even ship new common targets - which are installed with MSBuild. The .targets and .props files contained here ship in NuGet packages, which can be updated easily and allow for one project to stay on older targets, while other projects upgrade to newer versions. Some/most of these .targets and .props files should be able to be reused in other .NET projects, not just ".NET Core" projects.

Of course we are just starting down this path, and we can't change everything all at once. But, from my view, this is the direction we are currently headed.

kzu · 2016-09-08T15:19:11Z

With that goal in mind, I wholeheartedly agree :)

I'd start by renaming all Microsoft.NETCore.* files to Microsoft.NET.* then, since otherwise it seems like it's for .NETCore only ;)

Generate AssemblyInfo attributes during build

Add DynamicDependentFile capability for nesting rules

nguerrera reviewed Aug 23, 2016
View reviewed changes

eerhardt reviewed Aug 23, 2016
View reviewed changes

nguerrera mentioned this pull request Aug 24, 2016

Update CLI version #88

Merged

eerhardt reviewed Aug 25, 2016
View reviewed changes

nguerrera added 6 commits August 25, 2016 15:31

Generate AssemblyInfo attributes during build

5ebd0cd

Allow 4 parts in version

4e6268a

Fix #87

Move assembly info to project in template

99446a5

Add basic test coverage for generated assembly info

db8fcbf

Add OS check in test to workaround corefx bug for now

129a841

nguerrera mentioned this pull request Aug 25, 2016

Revert OS check when corefx FileVersionInfo bug is fixed #96

Closed

Merge branch 'master' into gen-assembly-info

512e5fd

Conflicts: src/Tasks/Microsoft.NETCore.Build.Tasks/Microsoft.NETCore.Build.Tasks.csproj

nguerrera merged commit 09567f4 into dotnet:master Aug 26, 2016

nguerrera deleted the gen-assembly-info branch August 26, 2016 17:58

nguerrera added a commit that referenced this pull request Oct 10, 2016

Merge pull request #81 from nguerrera/gen-assembly-info

3e8a93a

Generate AssemblyInfo attributes during build

eerhardt mentioned this pull request May 10, 2017

Create symbols packages, add serviceable attribute, and update assembly info dotnet/core-setup#2331

Merged

mmitche pushed a commit to mmitche/sdk that referenced this pull request Jun 5, 2020

Merge pull request dotnet#81 from aspnet/ap/aDAddDynamicCapability

4ee38c0

Add DynamicDependentFile capability for nesting rules

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Generate AssemblyInfo attributes during build #81

Generate AssemblyInfo attributes during build #81

nguerrera commented Aug 23, 2016 •

edited

nguerrera Aug 23, 2016

natidea Aug 23, 2016

nguerrera Aug 23, 2016

davkean Aug 23, 2016

nguerrera Aug 23, 2016

nguerrera Aug 23, 2016

davkean commented Aug 23, 2016

davkean commented Aug 23, 2016

eerhardt Aug 23, 2016

nguerrera Aug 23, 2016

rainersigwald Aug 23, 2016

eerhardt Aug 23, 2016

brthor Aug 23, 2016

eerhardt commented Aug 23, 2016

nguerrera commented Aug 23, 2016

davkean commented Aug 23, 2016 •

edited

rainersigwald commented Aug 23, 2016

nguerrera commented Aug 23, 2016

eerhardt commented Aug 23, 2016

nguerrera commented Aug 24, 2016

rainersigwald commented Aug 24, 2016

nguerrera commented Aug 24, 2016

nguerrera commented Aug 24, 2016

eerhardt commented Aug 24, 2016

eerhardt Aug 25, 2016

nguerrera Aug 25, 2016

nguerrera commented Aug 25, 2016

eerhardt commented Aug 25, 2016 •

edited

nguerrera commented Aug 25, 2016

kzu commented Sep 8, 2016

eerhardt commented Sep 8, 2016

kzu commented Sep 8, 2016

Generate AssemblyInfo attributes during build #81

Generate AssemblyInfo attributes during build #81

Conversation

nguerrera commented Aug 23, 2016 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

davkean commented Aug 23, 2016

davkean commented Aug 23, 2016

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

eerhardt commented Aug 23, 2016

nguerrera commented Aug 23, 2016

davkean commented Aug 23, 2016 • edited

rainersigwald commented Aug 23, 2016

nguerrera commented Aug 23, 2016

eerhardt commented Aug 23, 2016

nguerrera commented Aug 24, 2016

rainersigwald commented Aug 24, 2016

nguerrera commented Aug 24, 2016

nguerrera commented Aug 24, 2016

eerhardt commented Aug 24, 2016

Choose a reason for hiding this comment

Choose a reason for hiding this comment

nguerrera commented Aug 25, 2016

eerhardt commented Aug 25, 2016 • edited

nguerrera commented Aug 25, 2016

kzu commented Sep 8, 2016

eerhardt commented Sep 8, 2016

kzu commented Sep 8, 2016

nguerrera commented Aug 23, 2016 •

edited

davkean commented Aug 23, 2016 •

edited

eerhardt commented Aug 25, 2016 •

edited