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

Add support for dotnet build #41

Merged
merged 7 commits into from
Nov 6, 2019
Merged

Conversation

clairernovotny
Copy link
Contributor

@clairernovotny clairernovotny commented Nov 3, 2019

Fixes #17

This PR adds support for building with dotnet on CoreCLR. It uses Cecil 0.11, which added support for that.

It also converts all the projects to SDK-style, adds an Azure Pipelines yaml and auto versioning.

@clairernovotny
Copy link
Contributor Author

clairernovotny commented Nov 3, 2019

Progress, builds/doesn't error out, but doesn't work yet. Investigating.

Update: works. just had a non-signed assm cached in the SignedAssemblies directory so it was skipping based on the Mvid check.

@@ -217,5 +217,40 @@ private static byte[] GetKeyTokenFromKey(byte[] fullKey)

return hash.Reverse().Take(8).ToArray();
}

// From Cecil
// https://github.com/jbevain/cecil/pull/548/files
Copy link
Owner

Choose a reason for hiding this comment

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

So we're copying code from Cecil because it's not a public API? Would it make sense for Cecil to add public APIs for what we need?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Correct. I've suggested that but it's not likely to be soon. Fody has its own private copy of StrongNameKeyPair.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Choose a reason for hiding this comment

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

Why wouldn't this logic just live in Microsoft.CodeAnalysis? There is already a DesktopStrongNameProvider.

@@ -0,0 +1,60 @@
trigger:
Copy link
Owner

Choose a reason for hiding this comment

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

Did you hook this up to a pipeline anywhere and test it? How do you expect me to hook it up to CI?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Setup a free Azure DevOps pipeline? :)

I haven't tested it but I'm mostly sure it works ;) It's based on many others I've done.

@@ -0,0 +1,10 @@
{
"version": "0.1",
Copy link
Owner

Choose a reason for hiding this comment

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

What will the versions end up looking like here?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

They'll be 0.1.{height} since last increment.

Copy link
Owner

Choose a reason for hiding this comment

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

Does that mean that the NuGet package versions will also include the commit height? I'd prefer to avoid that.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Up to you -- I've found that no one seems to care about the patch version; you can see it in action in any of my libraries (rx/ix, humanizer, etc). It's a way to get a reproducible build/version number that auto versions. Driven by commit depth has been the most reliable way.

I can remove auto versioning if you have another approach you prefer.

Choose a reason for hiding this comment

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

I like GitVersion personally. I suppose you can drive it through GitInfo instead.

@clairernovotny
Copy link
Contributor Author

You can see it working by looking at the commits/builds here:
https://github.com/reactiveui/refit/commits/master

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.

Support dotnet execution tool
3 participants