search

brutaldev / StrongNameSigner

Strong-name sign third party .NET assemblies without the source code.
https://brutaldev.com/post/net-assembly-strong-name-signer
Other
327 stars 68 forks source link

Incompattible with PackageReference #33

Closed GieltjE closed 5 years ago

GieltjE commented 7 years ago

When installing via nuget with the new PackageReference it isn't properly installed (it appears to have an incorrect file structure).

brutaldev commented 7 years ago

I actually have no idea what you're talking about...

arledesma commented 7 years ago

@brutaldev I think that @GieltjE is asking for VS2017 PackageReference support.

brutaldev commented 7 years ago

Right, of course. I'll see if I can get around to this over the weekend.

brutaldev commented 7 years ago

Struggling to find time to look into this, if anyone wants to take a stab at figuring it out, I would welcome a pull request. In the meantime, just execute the console application as part of your build process which will work regardless of project format, NuGet version etc. Examples in the build process section.

GieltjE commented 7 years ago

Simply renaming the "build" folder to "lib" seems to solve the problem (remove the "obj" and "bin" folders before the first build). That would leave out any targeted building but for now would do the trick.

brutaldev commented 7 years ago

So in the NuGet package, should the build folder be lib instead? It used to be tools in v1.x and changed to build in 2.x. I think it was a convention for build scripts since the target file was introduced in 2.0.

GieltjE commented 7 years ago

I think so, looking at existing packages (haven't read the documentation) the directory structure is $userdir.nuget\$packagename\$version\lib\$target (e.g. C:\Users\Administrator.nuget\packages\mailkit\1.16.1\lib\net451, C:\Users\Administrator.nuget\packages\mailkit\1.16.1\lib\MonoAndroid10, C:\Users\Administrator.nuget\packages\mailkit\1.16.1\lib\Xamarin.iOS10). But with the files in just \lib without a target it appears to work just fine.

This seems to be supported by https://docs.microsoft.com/en-us/nuget/create-packages/creating-a-package

brutaldev commented 7 years ago

I'll have to take a look at this change carefully, there must be a reason I used build. I'll try check it out over the weekend when I have a bit more time to spend on this.

MichelZ commented 6 years ago

Was there any progress on this? Thanks

Galad commented 5 years ago

Hello @brutaldev Were you able to make any progress on this issue ?

Thanks

brutaldev commented 5 years ago

@Galad Nope, I simply haven't had the time to look into this, was hoping someone would be able to make a pull request for it.

brutaldev commented 5 years ago

Version 2.4.0 seems to work pretty well as a project reference now, path remains as "build" which will automatically identify the target file and use it as a build tool.