-
Notifications
You must be signed in to change notification settings - Fork 80
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
Update / Unify all package versions #162
Conversation
Add License to NuGet package as well Checked, we currently have no third-party notices brought over from the main toolkit.
This does use a branch of the sub-module, but it's needed together. If this works, we'll have to update the sub-module package references to point to the built versions of these packages - Then in Labs we update it to the same setup for versions and it should get all the proper versioned code now... |
Also Automates the InternalsVisibleTo into the AssemblyGeneration vs. specific file from template
ba9b8ca
to
068f479
Compare
Issues hopefully resolved now, was hitting limits on the attributes trying to use the new date, this was a helpful breakdown: https://stackoverflow.com/questions/37941195/the-specified-version-string-does-not-conform-to-the-required-format-major-mi |
Alright, was always adding a blank InternalsVisibleTo after last change, think got it now... |
TODO: We should clean this up in the future to not be needed, at least for Throw helpers to start.
ddead0b
to
0c8a06d
Compare
Looks maybe like actions/runner-images#7937 again, going to try re-running test process. Also keep forgetting to add build step to output more logs for that, will have to open a separate PR. |
Problem: We need a new set of packages unified from the same source set for our infrastructure to build in other repos.
This PR does that by triggering a push/update of all versions, along with a couple of things:
Should fix Fix NuGet pack Tooling-Windows-Submodule#7 (at least for this repo)
Related to Automate Versions of Packages Labs-Windows#133
This doesn't completely automate our package versioning, but centralizes it and uses the current day as part of the build number.
This should be a good interim until we go back to Nerdbank or use GitVersion or something else...
Main thing this is missing is hash or buildheight type addendums for multiple builds a day to be distinguished. Should be fine for now and packaging I believe.