I have several applications which are required to use the same assembly. This assembly may be changed regularly, and can be installed by different MSIs. For this reason, I do not want to put it in the GAC, it can become a deployment nightmare over time.
If I turn the CopyLocal attribute for this assembly to NO in the application, how do I tell the runtime where to look for the assembly?
E.g. the application is loaded in C:/Program Files/<some directory>/bin
The DLL is in C:/<some other directory>
Is it thus possible to load the assembly in this way?
I've had a look at <codebase>, but I'm not sure the assembly can be strongly signed. And probing seems to work only for the private paths specified as subdirectories of the application?
Please let me know. Thank you.
Use Assembly.LoadFrom to load the assembly into memory, then you can use Activator.CreateInstance to create an instance of your preferred type. You need to user reflection for this:
Assembly assembly = Assembly.LoadFrom("c:\\path\\MyDll.dll");
Type type = assembly.GetType("MyClass");
object instanceOfMyType = Activator.CreateInstance(type);
Take a look on reflection in order to create instances with parameters.
Why do you want to set CopyLocal to "No"? The usual way to avoid "DLL hell" (aka "deployment nightmare") is to ensure that DLL dependencies are copied into the same directory with your program. IMHO, this is the simplest, most straightforward way to guarantee you are loading the DLL you want.
Note also that if you sign the DLL, install it in the GAC, and then in your own program require a specific version (or a minimum version, depending on your needs), that should also address the "DLL hell" scenarios. I.e. the presence of other versions of the DLL won't conflict, because you've required a specific version and .NET can reliably distinguish the correct version from an incorrect one.
Barring those approaches...
It's not clear what your exact requirements are. However, if you are trying to provide a way to identify an assembly that's not in the usual assembly-loading paths, there are at least a couple of mechanisms you can use.
One way is to use ApplicationBase and PrivateBinPath to control how .NET searches for your assemblies.
Another way is to handle the System.AppDomain.AssemblyResolve event.
That event will be raised any time .NET tries to load a referenced assembly and can't find it. Your handler can then perform whatever search it needs to (or just use a fixed path for that matter), load the assembly itself (e.g. using Assembly.LoadFrom()), and then return that via the event's arguments object.
Note that the AssemblyResolve event is only raised if .NET can't find a DLL to load. So that would not be an appropriate solution if it's not tolerable to have a different instance of the DLL that satisfies the reference requirements for the program of that DLL.
Related
I have a C# COM-Interop assembly which I am calling from a Visual Basic 6 application. This assembly makes HTTP requests to send and retrieve JSON.
The assembly works fine when being testing with a C# test client.
However, when using it from with the VB6 app, the following error is returned:
"Could not load file or assembly 'Newtonsoft.Json, Version=4.5.0.0, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed' or one of its dependencies. The system cannot find the file specified."
The Newtonsoft.Json.dll is located within the same folder as the COM-Interop DLL (TLB).
Does the Newtonsoft.Json.dll need to be explicitly loaded? Or maybe placed in the GAC?
Hans provided a great explanation for why this happens. Let me offer a workaround for making this work without having to register the Json DLL in the GAC or copying it to the VB6 EXE directory.
In your COM-visible C# library, we can tell the .NET runtime environment to search for the Json DLL in the directory of the C# library instead of the "usual" paths. We do that by attaching our own handler to the AssemblyResolve event:
AppDomain.CurrentDomain.AssemblyResolve += (sender, e) =>
{
// We only want this workaround for one particular DLL
if (e.Name != "Newtonsoft.Json")
return null;
var myLibraryFolder = Path.GetDirectoryName(Assembly.GetExecutingAssembly().Location);
var path = Path.Combine(myLibraryFolder, "Newtonsoft.Json.dll");
return Assembly.LoadFrom(path);
};
Notes about this workaround:
This code only works if it is executed in your C# library before doing anything that might cause the jitter to load the JSON library. For example, neither your library nor any other .NET library in your VB6 process must call any method referencing types from the JSON library before this code is executed.
You modify the the behaviour of the whole process, not just your library. If your VB6 process uses another library using JSON, your "redirect" affects the other library as well.
This is a standard DLL Hell problem, it is caused by using the /codepage option for Regasm.exe. Or, more commonly, the Project > Properties > Build tab > "Register for COM interop" checkbox. Both do the same thing, they write the path to the DLL into the registry. It is a very good option to use when you are busy developing and testing the project, it avoids having to re-register the DLL into the GAC every single time you make a change.
But what it does not do is help the CLR find any dependencies. The normal probing rules remain in effect, it looks for an appname.exe.config file in the directory where the EXE is stored. And first looks in the GAC, next in the EXE path for dependencies. Configuration remains under control of the usual victim of DLL Hell, whomever has to maintain the EXE. Frequently the end-user. So, explicitly, it does not look in the directory where your [ComVisible] DLL is stored.
It is the mild kind of DLL Hell, just a plain file-not-found mishap. Much milder than the nasty kind, finding a file with the right name but the wrong version. In general a strong problem with Newtonsoft.Json.dll, there are about 35 versions in the wild. Having so many versions and it being such a popular library also begets the other kind of nastiness, the program using another COM server that also uses the DLL. But almost inevitably a different version. Tends to happen long after you declared your project finished. One of them is going to lose, 50-50 odds that it is you. 100% odds for the end-user.
Yes, the GAC solves this problem. Each library gets the version they ask for. Ideally Newtonsoft would solve this problem for you with an installer that deploys the DLL into the GAC. But it is not the kind of commitment that open source library writers ever want to provide. They want (and need) to make it your problem. Microsoft does this, but they also have Windows Update to ensure that critical bug and security fixes get deployed. And have a large number of people working on making sure that any new revisions are always backwards compatible with the original release so the version number doesn't have to change.
Do note that you can take advantage of Microsoft's commitment. You can also use the DataContractJsonSerializer and JavascriptSerializer classes to get this job done. Part of the framework, they rarely get it wrong.
Meanwhile, do keep mind that is just a file-not-found problem. You don't have to use the GAC on your dev machine, and it is better if you don't, it is just as easy to copy the file into the right place to keep the CLR happy. Which is the same directory as your VB6 test program. And, extra quirk with VB6, into C:\Program Files (x86)\Visual Studio\VB6 if you want to use the VB6 debugger. Do use the GAC when you deploy.
I have one assembly that's created already, say Static.dll, and a dynamic assembly I'm creating at runtime, say Dynamic. Dynamic creates some IL code to create a new type from Static.dll. When Dynamic is created (it saves successfully), the executable, when ran, errors out because it's unable to load the assembly Static.dll type. I believe this is happening since the Dynamic exe output can't find this dll (or at least this is my guess).
How can accomplish adding in this Static.dll reference so that when someone runs the resulting executable output of Dynamic that it can find the referenced types?
I know about Assembly.Load(), but this alone doesn't change anything. Or at least, I'm not sure what this gives me since I don't need to use the type at runtime, but rather when running the Dynamic executable.
Lastly, I control the Static.dll, so if there is something I can do with the project to fix it, It could be done, however, it does need to remain separate (I don't want to Emit this library for every time I create a dynamic assembly). Basically, I think I want to have my dynamic assembly to have a .assembly extern mscorlib in it's manifest save Static is place of the mscorlib.
Thanks
How can accomplish adding in this Static.dll reference so that when someone runs the resulting executable output of Dynamic that it can find the referenced types?
The reference will be added automatically. Note that normal assembly-probing rules apply when your dynamic assembly executes, so in order to find the assembly. You must (one of):
ship static.dll alongside dynamic.dll
put static.dll in the GAC (but please: don't do this!)
run dynamic.dll in a custom AppDomain with a custom probing-path configuration that lets static.dll be found
handle AppDomain.AssemblyResolve to provide static.dll
use something like ILMerge to fuse static.dll and dynamic.dll
I've a project which references to a 3th party library. The manufacturer of the library releases new versions on a regular basis. My ultimate goal is to be able to choose at runtime which version must be used during execution.
For now, I'm trying to load an assembly at runtime that has a higher version number than the one that was used during compilation. I compile my project, replace the 3th party library with a newer version and try to run the application. This is were I come into problems. I get an error saying:
"The located assembly's manifest definition does not match the assembly reference"
I was not supprised to see this error, since the assembly is strongly signed. I looked for ways to bypass this, but without any luck so far.
I thought that Binding Redirection could help me, but it has the disadvantage that you can't specify a range of "newversions". Any combination should work, older with newer version and vice versa.
<bindingRedirect oldVersion="1.2.7.0" newVersion="1.2.8.0" />
http://msdn.microsoft.com/en-us/library/eftw1fys.aspx
I've also looked at dynamic invocation, but then I loose type safety (my code extensively uses the types defined in the 3th party assembly). --> removing reference is difficult.
Removing the public key in the reference of the project definition didn't helped either. Any other assembly version then the one used during compilation fails.
<Reference Include="<assemblyname>">
<SpecificVersion>False</SpecificVersion>
<HintPath>..\..\Dependencies\<manufacturer>\1.2.7.0\<assemblyname>.dll</HintPath>
</Reference>
Note:
The logic to load and unload assemblies at runtime already exists.
There's no interface available for the 3th party library
You can 'fix' this issue (work around is probably a better description) by handling the AssemblyResolve event on the AppDomain. Handling this event gives your code a chance to provide the assembly that needs to be loaded when all the normal methods of finding an assembly have failed to locate a matching version.
Inside the event handler you will need to check the ResolveEventArgs.Name property to see if the assembly is the one you need to load. The Name property will be the long name of the assembly being loaded - i.e. 'Widget.Net, Version=1.2.3.4, Culture=neutral, PublicKeyToken=xxxxxxxxxxx'.
Once the correct load request has been identified, simply load the correct version of the assembly (Assembly.LoadFrom, Assembly.Load, Assembly.LoadWithPartialName) and return it from the event handler. Note that Assembly.LoadWithPartialName is marked as obsolete, but seems to be the only way to handle this issue if the target assembly is in the GAC.
// application initialization
AppDomain.CurrentDomain.AssemblyResolve += CurrentDomain_AssemblyResolve;
private Assembly CurrentDomain_AssemblyResolve(object sender, ResolveEventArgs args)
{
if (args.Name.StartsWith("Widget.Net, Version="))
{
Assembly result = Assembly.LoadFrom("Widget.Net.dll");
return result;
}
return null;
}
It's important to be aware that while this 'solves' the problem, it's not a good solution in any sense. It completely subverts the normal version and strong name checking of assemblies used by the .Net framework. It's something that you do when you have no other option because (as in the question) a vendor has messed up versioning their assembly. You are also relying on their being no breaking changes to the classes defined in the assembly between the referenced version and the loaded version - i.e. that all the classes, properties, methods etc that you use still exist and have the same signatures.
To maintain at least a pretence of security, it would be a very good idea to at least check in the AssemblyResolve event handler that:
The assembly version loaded is newer than the version requested
The public key tokens of the loaded and requested assemblies match
I have a project, i.e. library.exe. In this I have referenced an assembly (logging.dll ver 1.0.3.0) and I have given this assembly a strong name.
Now suppose I changed a method in logging.dll and made version 1.0.4.0.
Now when I copy/replaced the old DLL with this new one I got an exception.
I know that exception is because I have changed version number of the DLL. As it was a strong name DLL it's not allowed unless I rebuilt library.exe.
What I want to say with above story is
Use strong name with assembly only when we have to add it to GAC.
If we have an application where individual assemblies requires updating do not use strong named assemblies.
Am I correct with point 1 and 2?
When should strong named assemblies not be used?
What are the disadvantages of "strong named assembly"?
It is only really needed if you want to place your assemblies in the GAC, but it also helps against tampering. It is fairly easy to change the code in an assembly so this gives bad people an advantage. When you are using strong named assemblies you are signing it with a private key only you have. People could still change your assembly, but they can't give it the same strong name, because they do not have your private key. In that case .Net refuses the assemly tamperd with. When they sign your assembly with a new private key the .Net still refuses to load it since the identity of the assembly has changed.
There are several ways to solve the versioning problem. When your application wants to load a v1 assembly you could tell it to look voor a v2 anyway. See here for more information. The other option would be not to change the Assembly Version at all, but to change the File Version of the assembly only. For .Net the assemblies are the same, but you and your installer can still see which one is newer. See the AssemblyFileVersion attribute.
Both correct.
You don't need a StrongName if your signing the assembly afterwards, like with a real certificate.
In my oppinion strong naming is not realy worth anything, see this link for example. Well you need it for placing an assembly into the GAC but that's it.
Here what i am looking for is where should i expect/suggest the dynamic dll will be present?
should i use the location CurrentDirectory+AssemblyName for loading?
or should i be using the location Assembly.CodeBase property?
i am trying to use the Assembly.LoadFile(path).
Basically i want to load that assembly only if that is added to the solution.
it is supplied alongside my application , not a standard .net dll
The simplest way to do this is to simply ensure that the dll is in your probing path (search) and (as Tuzo noets), use Assembly.Load. If you want to load a dll from outside your path (and not in the GAC) then it gets tricky. There is Assembly.LoadFile / Assembly.LoadFrom, but then you need to worry about the load-context; you can quickly find that you get problems with the dlls that your dynamic code uses.
Another way of simplifying things is to use a separate AppDomain; this new AppDomain can have a different base/bin - allowing you to bring in the right dlls (and unload it when you want). You can either use CreateInstanceAndUnwrap (which establishes a remoting hook between two AppDomains, using a MarshalByRefObject proxy), or (for one-shot use) you can simply execute the new AppDomain with ExecuteAssembly.
I covered a range of these points in GAC, Assembly Resolution , and all that Jazz
I should be using CodeBase property of the CurrentExecuting directory to get the location,
because the CurrentDirectory could be changed at any point using the
System.Environment.CurrentDirectory = somelocation.