Update 2015-11-17
It seems that vNext assemblies (Microsoft.AspNet) are now signed (have strong names).
Check the following thread on GitHub:
Assemblies are now strong named #109
I want to create a digital signed assembly, which will use types implemented in one of the vNext assemblies. At this moment, vNext assemblies do not have a strong name attribute. As a result, the following error occurs while building a solution:
"Assembly generation failed -- Referenced assembly 'Microsoft.AspNet.Http' does not have a strong name"
Is this behavior a known issue (for example, related to the VS2015 CTP)? Is it going to be changed in the future? What is the recommended way to proceed?
Update 2015-11-17
As noted by Mikhail, nearly all the assemblies that are part of DNX 1, ASP.NET 5, and EF 7 have strong-name signatures.
They all use a private key that is checked in to the repo, so anyone can build the same DLLs with the same strong-name key. No "delay sign" or "test sign" process.
Original post 2015-02-11
There are no current plans to strong-name sign all the DLLs in ASP.NET 5. (Source: I work on the project.)
And because strong-name are "viral" (a strong-name signed assembly must reference only other strong-name signed assemblies), that means you cannot strong-name any assembly that depends on ASP.NET 5.
Related
If there are more plugin classes in one Visual Studio assembly, do we have to make one signing (.snk file) for each class, or it is enough to make one signing for the whole assembly?
Also, is there any difference if i create .snk file before creating a plugin class or not?
It's a single key for each assembly. Keys can be shared between assemblies.
And no, your key can be created before your assembly is.
Related to this question here, I am trying to create an installer which installs DLLs on the target user's PC and makes them available to the Visual Studio Reference Manager (Project > Add References)
I have figured out that to make an assembly visible to the .NET4.0 Reference Manager, I need to add this Registry Key
Key: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319\AssemblyFoldersEx\MyAsm
Value: <Directory on target PC of .NET4.0 assembly>
And for .NET4.5, I need this key
Key: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.5.50709\AssemblyFoldersEx\MyAsm
Value: <Directory on target PC of .NET4.5 assembly>
However I now have a problem. When I go to Add-References, I see something like this
So my question is, what is the best practice here for distributing multiple DLLs compiled to different .NET Frameworks (e.g. .NET4.0, .NET4.0 Client Profile, .NET4.5) and targeting different machines (x86, x64, AnyCPU) so that only one version shows up in Add-References OR So that versions can be differentiated in the Add-References dialog?
In general the best practice is to not mess with the user's registry. Do note that a programmer won't expect to find a non-Microsoft assembly in the Framework list so might never even look there. The added convenience is fairly minor, the user can simply use the Browse button to pick the reference assembly you copied onto his machine. Albeit that you do need to provide him with a hint on where to look. Not much of a problem when you use the standard c:\program files\company\product naming strategy.
Avoiding the duplicate is otherwise easy. If your assembly is compatible with .NET 4.0 then only modify the v4.0.30319 key. A project that targets 4.5 will include 4.0 assemblies in the list. If you require 4.5 for some reason then modify the v4.5.50709 key.
So I've looked around to try to find some posts on this and there are many but none that address my specific question (that I could find).
I am trying to add some DLL's in my project but few of them are coming from :
C:\Windows\Microsoft.NET\Framework\v3.5\XXX.YYY.dll
and what I expecting this should be coming from GAC.
Please suggest me the best practice to reference the Dll's in Visual Studio.
That's not the way it works. When you use Project + Add Reference then you always add a reference assembly. This is never an assembly from the GAC. The GAC is a runtime implementation detail, it is only ever used to supply assemblies when your program executes, never when it is built.
It is very important that it works that way, the content of the GAC on your machine will not match the content of the GAC on your user's machine. Lots of DLL Hell countermeasures are in place to ensure the mapping of your reference assembly to the user's GAC content is taken care of with good diagnostics when the user's machine isn't configured correctly to execute your program.
This is also the reason that you cannot directly look at the GAC folders when you navigate to c:\windows\assembly with Explorer. A shell extension handler hides the details to stop you from making a mistake like adding a GAC-ed assembly as a reference assembly. This same extension handler is not installed for the .NET 4 assemblies, you can look at c:\windows\microsoft.net\assembly and see the structure of the GAC. Do not assume that it is now okay to add references from there, reference assemblies are even more important in .NET 4, they are completely different from the runtime assemblies.
So seeing the reference assembly stored in C:\Windows\Microsoft.NET\Framework\v3.5 is completely normal, that's the home directory for .NET 3.5 specific reference assemblies, like System.Core.dll. For .NET 4 projects the reference assemblies are stored in c:\program files\reference assemblies, they should not reference C:\Windows\Microsoft.NET\Framework\v4.0.30319. Check this answer to see what kind of undiagnosable misery can be caused by not using the correct reference assemblies.
Those assemblies are assemblies of the .NET Framework 3.5. The assembly cache is located at
%SystemRoot%\assembly
You may distribute the .NET Framework 3.5 (scroll the the end of the page) together with your project. Aso if you are using VS Setup projects you can simply use the properties page to reference it.
To reference those assemblies you can easily right-click "References" > "Add Reference" and choose the assembly from the .NET tab. For referencing GAC assemblies refer to this question.
Point 1):
In one solution called CustomBehaviorsSolution, I have two projects - one is class library and another is silverlight class library project. The silverlight class library project has the class files which are 'linked' to the files of the first project. The solution compiles successfully.
Point 2):
I have another solution which has one silverlight application project and another desktop application project. The silverlight application project has the assembly refernce of the silverlight class library mentioned in Point 1 above. The desktop application project has the assembly reference to the class library mentioned in point 1 above.
Now, when I modify or add any class to the project mentioned in point 1 above and update their references in the projects in the solution 2; I experienced some weird behavior.
The desktop application project gets the new changes from the referred assembly whereas the SILVERLIGHT application project does not get the same changes from the referred assembly.
In ILDASM i saw the referred assemblies of point 1 above and they are alright. The problem is that the silverlight application project is not reading the updations from the assembly reference.
Can someone please help?
(I have been removing and then adding the assembly references.)
I'm using VS 2010 and Silverlight 4.0. (After ensuring almost everything, now I think that it might be a bug in VS 2010 or SL 4.0 ! Possible?
I created the new solution altogether (mentioned in point 2) and then added necessary assembly references and now everything is fine.
It seems that the previous solution was corrupted due to some reason.
A solution was just converted from VS 2008 to VS 2010. My VS 2010 build is failing with the popular "The type or namespace X could not be found". When I go to the project and go to Add References and add the appropriate project dll, the class name appears in blue text as if .NET found the correct class. However, when I go to the Build menu and select "Build Solution" I get the "namespace not found error" and the class name is no longer blue.
Thanks.
Your project is probably using the .NET 4.0 Client Profile, rather than the full .NET 4.0 framework.
Go to Project > Properties > Application and set "Target framework" to .NET Framework 4.
For some reason Microsoft set this as the default framework instead of the full one for projects in VS2010, and compilation fails with this cryptic error message for any referenced types/namespaces in assemblies which were built against the full framework.