mirror of
https://github.com/brutaldev/StrongNameSigner.git
synced 2026-04-25 19:36:02 +03:00
[GH-ISSUE #33] Incompattible with PackageReference #29
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @GieltjE on GitHub (Mar 31, 2017).
Original GitHub issue: https://github.com/brutaldev/StrongNameSigner/issues/33
When installing via nuget with the new PackageReference it isn't properly installed (it appears to have an incorrect file structure).
@brutaldev commented on GitHub (Mar 31, 2017):
I actually have no idea what you're talking about...
@arledesma commented on GitHub (Mar 31, 2017):
@brutaldev I think that @GieltjE is asking for VS2017 PackageReference support.
@brutaldev commented on GitHub (Mar 31, 2017):
Right, of course. I'll see if I can get around to this over the weekend.
@brutaldev commented on GitHub (Apr 9, 2017):
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 on GitHub (May 15, 2017):
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 on GitHub (May 15, 2017):
So in the NuGet package, should the
buildfolder belibinstead? It used to betoolsin v1.x and changed tobuildin 2.x. I think it was a convention for build scripts since the target file was introduced in 2.0.@GieltjE commented on GitHub (May 16, 2017):
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 on GitHub (May 16, 2017):
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 on GitHub (May 8, 2018):
Was there any progress on this?
Thanks
@Galad commented on GitHub (Dec 7, 2018):
Hello @brutaldev
Were you able to make any progress on this issue ?
Thanks
@brutaldev commented on GitHub (Dec 7, 2018):
@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 on GitHub (Sep 25, 2019):
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.