Skip to content
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

Clean up AssemblyInfo file updating #1249

Merged
merged 26 commits into from
Oct 12, 2017
Merged

Clean up AssemblyInfo file updating #1249

merged 26 commits into from
Oct 12, 2017

Conversation

bording
Copy link
Contributor

@bording bording commented Jul 1, 2017

This is still WIP, but here's what I have so far:

  • AssemblyInfoFileUpdate has been moved into GitVersionCore and renamed AssemblyInfoFileUpdater
  • The UpdateAssemblyInfo task has been rewritten to use AssemblyInfoFileUpdater

Things to do still:

  • Add a new way to generate the GitVersionInformation class
  • Remove the AssemblyInfoBuilder stuff from GitVersionTask
  • Look at the existing templates and see what changes might be needed
  • Figure out which of the other issues linked here should be fixed as part of this PR and which should be handled in subsequent PRs

Fixes #1242

@bording
Copy link
Contributor Author

bording commented Jul 1, 2017

I see there there are some test failures, but none of them look related to my changes...

@bording
Copy link
Contributor Author

bording commented Jul 7, 2017

Made a bit more progress. I've turned AssemblyVersionInfoTemplates into a more general purpose TemplateManager class, and I'm getting the add formats from embedded resources as well.

I've also started the GitVersionInformationGenerator implementation, which uses the TemplateManager to load its templates from embedded resources as well.

Copy link
Member

@asbjornu asbjornu left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I really like what this PR does. Please have a look at my comments and let me know what you think.

@@ -119,6 +119,9 @@
<Compile Include="GitVersionCache.cs" />
<Compile Include="GitVersionCacheKey.cs" />
<Compile Include="GitVersionCacheKeyFactory.cs" />
<EmbeddedResource Include="GitVersionInformationResources\Templates\GitVersionInformation.cs" />
<EmbeddedResource Include="GitVersionInformationResources\AddFormats\GitVersionInformation.cs" />
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since these are jumbled around anyway, would you mind grouping the related files together in the .csproj?

<Reference Include="Shouldly, Version=2.7.0.0, Culture=neutral, PublicKeyToken=6042cbcb05cbc941, processorArchitecture=MSIL">
<HintPath>..\packages\Shouldly.2.7.0\lib\net40\Shouldly.dll</HintPath>
<Private>True</Private>
<Reference Include="Shouldly, Version=2.8.3.0, Culture=neutral, PublicKeyToken=6042cbcb05cbc941, processorArchitecture=MSIL">
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since some of the build failures seems related to the upgrade of Shoudly, can you perhaps avoid that upgrade in this PR? On one of the Travis builds, this is the output:

The type initializer for Shouldly.ShouldlyConfiguration threw an exception.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can back this out, but the reason I upgraded it was that the older version was throwing an error about it not having a diff tool, so I was blocked. Upgrading it allowed it to use the VS diff tool.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would appreciate if you could install an external diff tool so we could have this PR free of any package upgrades. I hope that should take care of the build failures.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@asbjornu I do have an external diff tool, SourceGear DiffMerge, but Shouldly doesn't appear to know about it. Are there some docs I can follow to temporarily wire that up so I can actually run the tests but not need to bump the version?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, I'll see what I can do to get it working and I'll remove the package upgrade.

@bording
Copy link
Contributor Author

bording commented Jul 11, 2017

@asbjornu I have cleaned up the project files and removed the Shouldly update, but it looks like AppVeyor is still failing. I've run all of those failing tests locally, and they seem to work fine.

Regarding the rest of the changes to finish this PR up, I hope to have it wrapped up this week.

@asbjornu
Copy link
Member

@bording: Those build failures are indeed very strange. If someone else from @GitTools/developers should come by, here's the failure:

Error : ConfigProviderTests.CanWriteOutEffectiveConfiguration
System.Exception : Cannot find method in call stack with attribute NUnit.Framework.TestCaseAttribute
   at Shouldly.Configuration.FindMethodUsingAttribute`1.GetTestMethodInfo(StackTrace stackTrace, Int32 startAt) in C:\projects\shouldly\src\Shouldly.Shared\Configuration\FindMethodUsingAttribute.cs:line 20
   at Shouldly.ShouldMatchApprovedTestExtensions.ShouldMatchApproved(String actual, Func`1 customMessage, Action`1 configureOptions) in C:\projects\shouldly\src\Shouldly.Shared\ShouldlyExtensionMethods\ShouldMatchApprovedTestExtensions.cs:line 49
   at Shouldly.ShouldMatchApprovedTestExtensions.ShouldMatchApproved(String actual) in C:\projects\shouldly\src\Shouldly.Shared\ShouldlyExtensionMethods\ShouldMatchApprovedTestExtensions.cs:line 17
   at ConfigProviderTests.CanWriteOutEffectiveConfiguration() in C:\projects\gitversion\src\GitVersionCore.Tests\ConfigProviderTests.cs:line 177

@bording
Copy link
Contributor Author

bording commented Jul 16, 2017

Pushed up a few more changes, but didn't get as much done as I'd hoped I would. 😞

@asbjornu I started looking into turning the existing AssemblyInfoBuilder tests in GitVersionTask.Tests tests into new GitVersionInformationGenerator tests, but they're a lot more involved than I was expecting. In addition to using Shouldly to write the file output to disk, it's also compiling the code with Rosyln and loading the assembly into memory to test it.

Is it really important to keep this aspect in the new tests? It seems a bit excessive to me. Also, it only tests the C# and VB output, and not F#. I'm thinking that having the Shouldly output to verify the output looks correct would be enough here, especially considering that's all the AssemblyInfoFileUpdater tests do.

@bording
Copy link
Contributor Author

bording commented Jul 16, 2017

Hmm, still seeing those weird test failures. I see that other PRs have been merged recently, and the failures didn't happen on those branches, but I'm not sure what I've done here that would cause them. I guess I'll need to spend some time figuring that out since it doesn't look like it's going away on it's own...

@asbjornu
Copy link
Member

Compiling the generated files with Roslyn is a bit excessive, I agree. It's good to know that the generated content actually compiles (especially since it's just basic and unsafe string replacements), but we can probably move that to the build pipeline instead. @gep13, do you have Ideas on how we can have Cake do the instrumentation there instead of doing it within a test?

It's unfortunate that the tests are failing and that I don't have time assisting you. I'm back from holiday in a couple of weeks and might be able to take a closer look then. The best of luck meanwhile, though and thanks for this work, @bording! It's highly appreciated!

@bording
Copy link
Contributor Author

bording commented Aug 31, 2017

Just wanted to chime in and say that I'm still planning on getting back to finishing this. Lack of spare time and then vacation has conspired to prevent me from working on it recently.

Hope to get back to it soon!

@bording bording changed the title [WIP] Clean up AssemblyInfo file updating Clean up AssemblyInfo file updating Oct 8, 2017
@bording
Copy link
Contributor Author

bording commented Oct 8, 2017

@asbjornu With the changes I've just pushed up, I'm removing the WIP and think this is ready for a review.

I haven't added a way to create the GitVersionInformation file from GitVersionExe yet, but that wasn't something it could do before anyway, so it could be added as a followup PR since this one is large enough as-is.

@bording
Copy link
Contributor Author

bording commented Oct 8, 2017

Looks like those unrelated tests are still failing on AppVeyor 😢

@asbjornu
Copy link
Member

asbjornu commented Oct 9, 2017

@bording: Thanks for your work on this! ❤️ Those failing tests are bizarre. Especially because they're only failing on AppVeyor. Perhaps an upgrade of Shouldly can help?

@bording
Copy link
Contributor Author

bording commented Oct 9, 2017

@bording: Thanks for your work on this! ❤️ Those failing tests are bizarre. Especially because they're only failing on AppVeyor. Perhaps an upgrade of Shouldly can help?

I can try it and see if it makes a difference.

@dazinator
Copy link
Member

Quick look at the stack trace a few comments above, nunit attribute is mentioned - so could also check if updating nunit packages helps at all.

@bording
Copy link
Contributor Author

bording commented Oct 10, 2017

Dug into the Shouldly code a bit and I realized what was going on! The tests I added were calling ShouldlyConfiguration.ShouldMatchApprovedDefaults.LocateTestMethodUsingAttribute<TestCaseAttribute>();, but the failing tests were all using Test, not TestCase.

The configuration appears to be global, so I added ShouldlyConfiguration.ShouldMatchApprovedDefaults.LocateTestMethodUsingAttribute<TestAttribute>(); to the tests that were failing, and now everything is passing!

And, since those tests were all marked to not run on mono, that's why Travis wasn't failing.

@asbjornu Should I revert the Shouldly updates? Maybe go back to 2.8.3 instead of the beta?

@asbjornu
Copy link
Member

Excellent! 2.8.3 sounds fine.

@bording
Copy link
Contributor Author

bording commented Oct 10, 2017

Excellent! 2.8.3 sounds fine.

Done!

@bording
Copy link
Contributor Author

bording commented Oct 10, 2017

Sigh, now it looks like 2.8.3 is causing Travis to fail because it added a Visual Studio difftool option, and looking for that is throwing.

I guess back to 2.7.0 it is!

@asbjornu
Copy link
Member

@bording: Fantastic work, thank you so much for this! ❤️

@asbjornu asbjornu merged commit 0678efa into GitTools:master Oct 12, 2017
@bording bording deleted the assemblyInfo branch October 12, 2017 12:58
@bording bording mentioned this pull request Nov 5, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

GitVersionInformation in SDK-style projects
3 participants