[GH-ISSUE #29] NuGet package not installed in .NET Standard 1.3 library

kerem commented

2026-02-25 21:30:29 +03:00

Owner

Originally created by @epsitec on GitHub (Jan 19, 2017).
Original GitHub issue: https://github.com/brutaldev/StrongNameSigner/issues/29

I am working in Visual Studio 2015 (Update 3) and I created a *.csproj as a Class Library (PCL) which I then migrated to .NET Standard 1.3, by going to the properties of the project file, under Library and change the Targeting to .NETStandard1.3.

I then installed NuGet package Brutal.Dev.StrongNameSigner.2.1.0, expecting it to pop up in my packages folder. But nothing happens. The strong name signer tool cannot be used in conjunction with a .NET Standard PCL project.

I had to add another standard .NET project to my solution and include the NuGet package for Brutal.Dev.StrongNameSigner.2.1.0 over there in order to get it into packages.

Originally created by @epsitec on GitHub (Jan 19, 2017). Original GitHub issue: https://github.com/brutaldev/StrongNameSigner/issues/29 I am working in Visual Studio 2015 (Update 3) and I created a `*.csproj` as a _Class Library (PCL)_ which I then migrated to .NET Standard 1.3, by going to the properties of the project file, under _Library_ and change the _Targeting_ to `.NETStandard1.3`. I then installed NuGet package `Brutal.Dev.StrongNameSigner.2.1.0`, expecting it to pop up in my _packages_ folder. But nothing happens. The strong name signer tool cannot be used in conjunction with a .NET Standard PCL project. I had to add another standard .NET project to my solution and include the NuGet package for Brutal.Dev.StrongNameSigner.2.1.0 over there in order to get it into _packages_.

kerem closed this issue

2026-02-25 21:30:29 +03:00

kerem commented

2026-02-25 21:30:29 +03:00

Author

Owner

@brutaldev commented on GitHub (Jan 19, 2017):

The package does not define any specific framework, it's a tool so it won't target any framework because it does not add references. Will have to investigate this one when I get some time.

@brutaldev commented on GitHub (Jan 19, 2017): The package does not define any specific framework, it's a tool so it won't target any framework because it does not add references. Will have to investigate this one when I get some time.

kerem commented

2026-02-25 21:30:29 +03:00

Author

Owner

@epsitec commented on GitHub (Jan 19, 2017):

@onovotny might be of some help here!

@epsitec commented on GitHub (Jan 19, 2017): @onovotny might be of some help here!

kerem commented

2026-02-25 21:30:29 +03:00

Author

Owner

@clairernovotny commented on GitHub (Jan 19, 2017):

Project.json does not install packages into the solution package folder. Instead it uses a shared per user location.

@clairernovotny commented on GitHub (Jan 19, 2017): Project.json does not install packages into the solution package folder. Instead it uses a shared per user location.

kerem commented

2026-02-25 21:30:29 +03:00

Author

Owner

@epsitec commented on GitHub (Jan 19, 2017):

Ah, so the issue is with the tooling. So I can expect to have this solved with the new and shiny *.csproj in Visual Studio 2017?

@epsitec commented on GitHub (Jan 19, 2017): Ah, so the issue is with the tooling. So I can expect to have this solved with the new and shiny `*.csproj` in Visual Studio 2017?

kerem commented

2026-02-25 21:30:29 +03:00

Author

Owner

@clairernovotny commented on GitHub (Jan 19, 2017):

Depends on what you're trying to do. Nuget v3 in general uses a per user location instead of per solution location. It was a significant optimization. The only way to install a package to a specific directory is by using the nuget install command and specifying a directory.

@clairernovotny commented on GitHub (Jan 19, 2017): Depends on what you're trying to do. Nuget v3 in general uses a per user location instead of per solution location. It was a significant optimization. The only way to install a package to a specific directory is by using the nuget install command and specifying a directory.

kerem commented

2026-02-25 21:30:29 +03:00

Author

Owner

@epsitec commented on GitHub (Jan 19, 2017):

Our build environment requires that the packages get installed in a packages folder under the control of the solution (for instance because some of the unsigned assemblies in the packages need to be signed, and we don't want to do that in a global user location).

Switching to *.csproj without project.json on Visual Studio 2017 to compile .NET Standard class libraries means that msbuild will be in charge, right? Can we then still specify the path of the packages folder used by the solution?

@epsitec commented on GitHub (Jan 19, 2017): Our build environment requires that the packages get installed in a _packages_ folder under the control of the solution (for instance because some of the unsigned assemblies in the packages need to be signed, and we don't want to do that in a global user location). Switching to `*.csproj` without `project.json` on Visual Studio 2017 to compile _.NET Standard_ class libraries means that msbuild will be in charge, right? Can we then still specify the path of the _packages_ folder used by the solution?

kerem commented

2026-02-25 21:30:29 +03:00

Author

Owner

@clairernovotny commented on GitHub (Jan 19, 2017):

In VS 2017, it uses <PackageReference> in the csproj and still uses a shared location. I believe there is a way to specify a specific packages location within a nuget.config file that you could have alongside your sln, but keep in mind that with netstandard, it has a large footprint. Also, package contents are re-validated on restore and if the contents don't match the targets, they're re-restored. You basically cannot alter the contents of a package's directory.

If you need to use a tool to alter a package contents, then you'd need to do it at build-time in the pipeline and put it somewhere like the obj dir (or some other temp location). You can't really modify nuget references in-place.

@clairernovotny commented on GitHub (Jan 19, 2017): In VS 2017, it uses `<PackageReference>` in the csproj and still uses a shared location. I believe there is a way to specify a specific packages location within a nuget.config file that you could have alongside your sln, but keep in mind that with netstandard, it has a large footprint. Also, package contents are re-validated on restore and if the contents don't match the targets, they're re-restored. You basically cannot alter the contents of a package's directory. If you need to use a tool to alter a package contents, then you'd need to do it at build-time in the pipeline and put it somewhere like the obj dir (or some other temp location). You can't really modify nuget references in-place.

kerem commented

2026-02-25 21:30:30 +03:00

Author

Owner

@epsitec commented on GitHub (Jan 19, 2017):

Thank you, I'll give Visual Studio 2017 a try when it gets ripe for larger public consumption.
For now we are using a NuGet.config file which looks like this:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <config>
	<!-- https://docs.nuget.org/consume/nuget-config-settings -->
    <add key="repositoryPath" value="./packages" />
  </config>
</configuration>

I am aware of the fact that modifying the packages contents is a slippery solution, but until now, the only really practical solution to consume unsigned NuGet assemblies is to let the StrongNameSigner tool do its magic and strong-name the assemblies in the <Target Name="BeforeBuild"> step.

Another approach would be to use a custom NuGet server which would strong name the unsigned assemblies on the fly, as explained in Maarten Balliauw's blog post.

@epsitec commented on GitHub (Jan 19, 2017): Thank you, I'll give Visual Studio 2017 a try when it gets ripe for larger public consumption. For now we are using a NuGet.config file which looks like this: ```xml <?xml version="1.0" encoding="utf-8"?> <configuration> <config>  <add key="repositoryPath" value="./packages" /> </config> </configuration> ``` I am aware of the fact that modifying the `packages` contents is a slippery solution, but until now, the only really practical solution to consume unsigned NuGet assemblies is to let the `StrongNameSigner` tool do its magic and strong-name the assemblies in the `<Target Name="BeforeBuild">` step. Another approach would be to use a custom NuGet server which would strong name the unsigned assemblies on the fly, as explained in [Maarten Balliauw's blog](https://blog.maartenballiauw.be/post/2014/09/10/automatically-strong-name-signing-nuget-packages.html) post.

kerem commented

2026-02-25 21:30:30 +03:00

Author

Owner

@clairernovotny commented on GitHub (Jan 19, 2017):

@epsitec the nuget config file is your best option for now, but as mentioned, it's tough as restore will overwrite things.

Just curious what's driving the need for this to begin with? StrongNaming is not a security measure; Authenticode signing handles that.

@clairernovotny commented on GitHub (Jan 19, 2017): @epsitec the nuget config file is your best option for now, but as mentioned, it's tough as restore will overwrite things. Just curious what's driving the need for this to begin with? StrongNaming is not a security measure; Authenticode signing handles that.

kerem commented

2026-02-25 21:30:30 +03:00

Author

Owner

@epsitec commented on GitHub (Jan 19, 2017):

Our DLLs and EXEs and signed with Authenticode and we use that to secure against tampering.

Strong names happen to be handy to classify assemblies based on where they come from. We use reflection a lot, and being able to identify an assembly as ours very quickly is a good thing. And some part of our code relies on the strong name to decide whether a plug-in may be loaded or not.

Should we ditch the strong names altogether and rely on Authenticode (or on naming conventions) for what we do now? I don't really know what the implications would be. And this would mean that we would have to remove strong names in all our assemblies, and products...

@epsitec commented on GitHub (Jan 19, 2017): Our DLLs and EXEs and signed with Authenticode and we use that to secure against tampering. Strong names happen to be handy to classify assemblies based on where they come from. We use reflection a lot, and being able to identify an assembly as _ours_ very quickly is a good thing. And some part of our code relies on the strong name to decide whether a plug-in may be loaded or not. Should we ditch the strong names altogether and rely on Authenticode (or on naming conventions) for what we do now? I don't really know what the implications would be. And this would mean that we would have to remove strong names in all our assemblies, and products...

kerem commented

2026-02-25 21:30:30 +03:00

Author

Owner

@clairernovotny commented on GitHub (Jan 19, 2017):

I would say that you'd be better off validating the authenticode signature if you're worried about tampering and origin. Anyone can do a "public sign" of an assembly using only the public key and if strong name validation is disabled (which it is by default unless it's in the GAC, in another appdomain, or shadow copied), then nothing is preventing someone from modifying and resigning the assembly. Only validating the authenticode signature and the certificate properties would give you that.

So any code making security decisions based on a strong name is inherently broken.

@clairernovotny commented on GitHub (Jan 19, 2017): I would say that you'd be better off validating the authenticode signature if you're worried about tampering and origin. Anyone can do a "public sign" of an assembly using only the public key and if strong name validation is disabled (which it is by default unless it's in the GAC, in another appdomain, or shadow copied), then nothing is preventing someone from modifying and resigning the assembly. Only validating the authenticode signature and the certificate properties would give you that. So any code making security decisions based on a strong name is inherently broken.

kerem commented

2026-02-25 21:30:30 +03:00

Author

Owner

@epsitec commented on GitHub (Jan 19, 2017):

I was not aware of the fact that anyone could do a public sign without having to first disable strong name validation via the registry. Thank you very much. I now better understand why there was all this debate about signing (or not) assemblies over a year ago.

@epsitec commented on GitHub (Jan 19, 2017): I was not aware of the fact that anyone could do a _public sign_ without having to first disable strong name validation via the registry. Thank you very much. I now better understand why there was all this debate about signing (or not) assemblies over a year ago.

kerem commented

2026-02-25 21:30:30 +03:00

Author

Owner

@brutaldev commented on GitHub (Jan 19, 2017):

The strong name signer is literally tampering with your assemblies an re-applying the strong name... The public key header section is well known and you can easily add it again. Authenticode has it's failures as well, such as introducing altered wintrust.dll files that always pass the digital signature check and doing basic P/Invoke interception (there is no managed way of checking a signature). The barriers you may put in place to prevent loading files that aren't your just make it difficult for most to circumvent, but if someone really wanted to there will unfortunately always be a way around it.

@brutaldev commented on GitHub (Jan 19, 2017): The strong name signer is literally tampering with your assemblies an re-applying the strong name... The public key header section is well known and you can easily add it again. Authenticode has it's failures as well, such as introducing altered `wintrust.dll` files that always pass the digital signature check and doing basic P/Invoke interception (there is no managed way of checking a signature). The barriers you may put in place to prevent loading files that aren't your just make it difficult for most to circumvent, but if someone really wanted to there will unfortunately always be a way around it.

Rows
Columns

[GH-ISSUE #29] NuGet package not installed in .NET Standard 1.3 library #25