How can I profile Signed Assemblies with VS 2010 or VS 2013

Question

I have a website that uses AjaxControlToolkit.dll and Log4Net.dll.

When I try to run the performance profiling tool in VS 2010 on it it gives me the following warning:

AjaxControlToolkit.dll is signed and instrumenting it will invalidate its signature. If you proceed without a post-instrument event to re-sign the binary it may not load correctly.

Now, if I choose the option to continue without re-signing, the profiling starts but the assembly doesn't load and gives an ASP.NET exception.

Inflorescence

Note that the [PathofDLL] (per Vince & ghusse answers) will be located in the obj project folder, not the bin folder. – Crews

Answer 1

If you're doing this on a development machine, you can disable strong name verification altogether with sn -Vr *. If you do this, you don't have to resign anything. This approach can be a security risk, but if you are comfortable with it, it's easier than resigning.

Specifically, from MSDN, it says:

Registers assembly for verification skipping. Optionally, you can specify a comma-separated list of user names. If you specify infile, verification remains enabled, but the public key in infile is used in verification operations. Assembly can be specified in the form *, strongname to register all assemblies with the specified strong name. Strongname should be specified as the string of hexadecimal digits representing the tokenized form of the public key. See the -t and -T options to display the public key token.

And the security risk:

Caution: Use this option only during development. Adding an assembly to the skip verification list creates a security vulnerability. A malicious assembly could use the fully specified assembly name (assembly name, version, culture, and public key token) of the assembly added to the skip verification list to fake its identity. This would allow the malicious assembly to also skip verification.

Stockroom

.. and one must not forget the opposite: sn -Vu * (This is to re-enable verification with this method) – Stylite

sn -Vx also re-enables verification of all assemblies. To quote the docs: "Removes all verification-skipping entries.". – Irregular

For profiling into 3rd party assemblies, where I do not have the signing key, this proved to be the only solution I could get working – Cabinetmaker

So ... sn -Vu * or sn -Vx?? :) – Janaye

I did that, but the "is signed and instrumenting it will invalidate its signature" dialog still pops up and I cannot profile. What else am I missing? A Visual Studio restart did not help. – Bioclimatology

Click "Yes" and you'll be able to proceed with the analysis. – Currie

Much faster than adding post-instrumentation events, you don't have to remember to add/remove entries, and it can be easily undone using the Vx command. – Coastwise

On VS 2019, I had to make sure to use the 32-bit version of sn.exe in order for it to work. Not sure if the x64 version would work for x64 iisexpress. – Furunculosis

Answer 2

ghusse linked to a blog post giving the answer. The answer is described there. As he points out, you have to use a post-instrument event on each signed assembly.

It's easiest to call sn.exe directly:

"C:\Program Files\Microsoft SDKs\Windows\v7.0A\bin\sn.exe" -R [pathOfDll] [pathOfSNK]

Note that [pathOfDll] is located in the directory obj\Debug associated to the project.

Washerwoman

what is this answer? where should it be called? – Vanhoose

The answer is the link given by ghusse: blogs.msdn.com/b/ianhu/archive/2005/07/25/443021.aspx. – Washerwoman

This seems to have gotten me past the initial problems, unfortunately I'm running into issues getting the web server to launch after that. I will note too though that implementing this event for each assembly is a pain when you have 30+ assemblies like we do in our project. – Uriia

sn.exe may be located on different location. For example in my case, it was located at "C:\Program Files (x86)\Microsoft SDKs\Windows\v8.1A\bin\NETFX 4.5.1 Tools\sn.exe". So search for sn.exe in Windows drive if you don't find it – Bb

Answer 3

The answer is described here. You have to use a post-instrument event on each signed assembly.

I could not manage to make it work "as is" with my installation of VS 2010. I had to call this command line as a post-build event on each dll :

"C:\Program Files\Microsoft Visual Studio 10.0\VC\vcvarsall.bat"   & sn -Ra [pathOfDll] [pathOfSNK]

Note that [pathOfDll] is located in the directory obj\Debug associated to the project.

Proselyte

Answer 4

The easiest way to get instrumentation work on signed binaries, which have not been re-signed, is to disable signature checks altogether. This is a machine wide setting that you can activate by registering an exception for the * pattern:

sn.exe -Vr *

This command must be executed from an elevated command prompt. You will find sn.exe in the SDK (in my case, I found it in C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bin).

When you are finished with testing, you should unregister the exception:

sn.exe -Vu *

or else your machine could be vulnerable to malicious code, since assemblies will be trusted even if they have been tampered with.

See also Access denied running sn.exe on Windows 7.

Hanson

Answer 5

The profiler probably changes the assembly and because it was previously signed. Apparently you need to add a post-instrument action that re-signs the assembly.

This could be a problem because you do not have the sn file that was used to sign the 3rd party assemblies.

Apportionment

Answer 6

Might have taken the lazy learning-new-things-free way out here, but I ended up solving this by writing a powershell script to unsign all the projects in my solution -- worked just fine. As part of the script, I save the original csproj files so I can revert them after. (you could also just undo changes in source control).

http://pastebin.com/UbABvz7d

should be able to revert by calling it passing the -revert switch.

Overalls

Due note that this might not be an option for all with a similar problem. CodeAnalysis rule Code Analysis rule CA2240 can give compile errors, and using the InternalsVisibleTo attribute will also fail with this approach. – Leary