Having references to non-strong named assemblies breaks

[martijnhoogendoorn]

When executing this tools as a pre-build in Visual Studio, references for the project need to be updated to reference the strong named version as well. A Visual Studio plugin would be very nice.

[brutaldev]

Hi,

The intention behind the utility is to sign third party assemblies first and then reference them in your project. I'm not sure why you would want to sign things prior to every build? If you were signing your own projects you would not be able to reference the unsigned assemblies in the first place. If you are not signing your project then what is the purpose of signing the third party assemblies (other than preventing them from being modified)?

If there is a legitimate use case for wanting to sign assemblies and update the project files with the signed version I'll consider adding this as a feature. Please let me know why you are trying to sign after you've already added references to an unsigned project?

Werner

[martijnhoogendoorn]

Hi Werner, Your name sounds quite Dutch, but I'll continue in English for now :) My scenario (I'd argue an increasingly common one) is as follow: I use NuGet to get packages installed and assemblies referenced. These assemblies are usually unsigned (Microsoft assemblies aside). When I start strong naming my solution projects, I end up with an uncompilable solution. Simply signing the assemblies once removes the option to upgrade the packages using NuGet package manager and becomes hard if you're using a Continuous Integration Server such as the one available in Team Foundation Server Online (where the build workflow restores packages, as you don't check in binaries ofcourse). This is my workflow and I think it needs a "on build" Visual Studio plugin (or actually, ideally a MSBuild task so it can be used on the CI server). Would you agree?

Thanks, Martijn.

Date: Sat, 19 Oct 2013 23:36:54 -0700 From: notifications@github.com To: StrongNameSigner@noreply.github.com CC: martijnhoogendoorn@live.nl Subject: Re: [StrongNameSigner] Having references to non-strong named assemblies breaks (#1)

Hi,

The intention behind the utility is to sign third party assemblies first and then reference them in your project. I'm not sure why you would want to sign things prior to every build? If you were signing your own projects you would not be able to reference the unsigned assemblies in the first place. If you are not signing your project then what is the purpose of signing the third party assemblies (other than preventing them from being modified)?

If there is a legitimate use case for wanting to sign assemblies and update the project files with the signed version I'll consider adding this as a feature. Please let me know why you are trying to sign after you've already added references to an unsigned project?

Werner

— Reply to this email directly or view it on GitHub.

[brutaldev]

Agreed. This is an interesting workflow but it makes sense to want to sign NuGet assemblies before they get added as a reference or just before it gets built. The challenge here would be to make it as noninvasive as possible without causing VS to notify the project file has changed during a build. Source control will also be interesting since you will check in references that will change on the build server unless you use your own SNK file (recommended).

Added a milestone to investigate this and come up with a possible solution.

[martijnhoogendoorn]

Let me know when you start thinking about it, I'd like to contribute if possible.

Date: Sun, 20 Oct 2013 07:28:56 -0700 From: notifications@github.com To: StrongNameSigner@noreply.github.com CC: martijnhoogendoorn@live.nl Subject: Re: [StrongNameSigner] Having references to non-strong named assemblies breaks (#1)

Agreed. This is an interesting workflow but it makes sense to want to sign NuGet assemblies before they get added as a reference or just before it gets built. The challenge here would be to make it as noninvasive as possible without causing VS to notify the project file has changed during a build. Source control will also be interesting since you will check in references that will change on the build server unless you use your own SNK file (recommended).

Added a milestone to investigate this and come up with a possible solution.

— Reply to this email directly or view it on GitHub.

[brutaldev]

No problem, you can start with letting me know which NuGet packages are unsigned so I can setup a test project to play around with. I'll probably start investigating custom MSBuild scripts tonight.

Werner

[martijnhoogendoorn]

All MvvmCross packages are unsigned, either targeting net45 or monoandroid22

Date: Sun, 20 Oct 2013 07:47:55 -0700 From: notifications@github.com To: StrongNameSigner@noreply.github.com CC: martijnhoogendoorn@live.nl Subject: Re: [StrongNameSigner] Having references to non-strong named assemblies breaks (#1)

No problem, you can start with letting me know which NuGet packages are unsigned so I can setup a test project to play around with. I'll probably start investigating custom MSBuild scripts tonight.

Werner

— Reply to this email directly or view it on GitHub.

[brutaldev]

I've actually found a really easy way to do this without having to develop a custom MSBuild task. You can call the console application before a build to sign the references so when it resolves them they are already signed and everything builds just fine.

Add an Exec element in your project file for each assembly you need signed (at the bottom):

<Target Name="BeforeBuild">
  <Exec ContinueOnError="false"
        Command="&quot;C:\Program Files\BrutalDev\.NET Assembly Strong-Name Signer\StrongNameSigner.Console.exe&quot; -a &quot;..\..\packages\MvvmCross.HotTuna.MvvmCrossLibraries.3.0.13\lib\net45\Cirrious.MvvmCross.Wpf.dll&quot;" />
</Target>

Use the same reference path to the NuGet packages that your project uses for files that are not signed. Now whenever a new package is downloaded, update the reference path and it will get signed before a build. The strong-name signer app files can also be copied into a tools folder in the repo so the build server has access to it without having to install.

At the moment you get a warning after the first run because the assemblies will now already be signed. I will do a small update to run the console in a mode that ignores already signed assemblies so it does not show warnings in Visual Studio.

[brutaldev]

v1.1.0.0 release and pushed.

Already signed assemblies now get ignored during a Visual Studio build. It's also easy to recursively sign all NuGet assemblies with a single -in console option pointing to your packages directory.

[martijnhoogendoorn]

Cool! I will this this out later today :)

Date: Mon, 21 Oct 2013 11:51:10 -0700 From: notifications@github.com To: StrongNameSigner@noreply.github.com CC: martijnhoogendoorn@live.nl Subject: Re: [StrongNameSigner] Having references to non-strong named assemblies breaks (#1)

I've actually found a really easy way to do this without having to develop a custom MSBuild task. You can call the console application before a build to sign the references so when it resolves them they are already signed and everything builds just fine.

Add an Exec element in your project file for each assembly you need signed (at the bottom):

Use the same reference path to the NuGet packages that your project uses for files that are not signed. Now whenever a new package is downloaded, update the reference path and it will get signed before a build. The strong-name signer app files can also be copied into a tools folder in the repo so the build server has access to it without having to install.

At the moment you get a warning after the first run because the assemblies will now already be signed. I will do a small update to run the console in a mode that ignores already signed assemblies so it does not show warnings in Visual Studio.

— Reply to this email directly or view it on GitHub.

[martijnhoogendoorn]

Does exactly what it advertises. With types referenced within the assembly, I do now get errors such as below, which force the use of the unsigned version still it seems: 2>c:\dev\A.Droid\Setup.cs(13,18,13,23): error CS0012: The type 'Cirrious.CrossCore.Droid.IMvxAndroidGlobals' is defined in an assembly that is not referenced. You must add a reference to assembly 'Cirrious.CrossCore.Droid, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null'. fyi, Setup derives from MvxAndroidSetup, defined in Cirrious.MvvmCross.Droid.dll, referencing Cirrious.CrossCore.Droid (unsigned). To me, this implies references in the binaries being signed should also be updated with the new FQN. Date: Mon, 21 Oct 2013 12:21:38 -0700 From: notifications@github.com To: StrongNameSigner@noreply.github.com CC: martijnhoogendoorn@live.nl Subject: Re: [StrongNameSigner] Having references to non-strong named assemblies breaks (#1)

v1.1.0.0 release and pushed.

Already signed assemblies now get ignored during a Visual Studio build. It's also easy to recursively sign all NuGet assemblies with a single -in console option pointing to your packages directory.

— Reply to this email directly or view it on GitHub.

[brutaldev]

Opened up a new issue for updating references inside assemblies: https://github.com/brutaldev/StrongNameSigner/issues/2