Accessing resources from merged assembly

dybalabj

I have a DLL with some icon files as resources that are accessed in a WPF XAML file. If I try to merge this DLL with my main executable in SmartAssembly (no other processing on it), I get a System.IO.FileNotFoundException indicating that my DLL can't be found, and thus my resource can't be loaded. If I embed the DLL instead of merge it, then my resource is loaded just fine. However, error reports for embedded assemblies don't show details like local and member variables, so I would prefer to merge the assembly instead.

Is there a way I can access a resource from an assembly that's been merged through SmartAssembly?

Thanks,

Brandon

Jessica R

Hi Brandon,

Thanks for your post!

It sounds like the resource is probably being called on by name, but merging the DLL containing the icon files has destroyed the namespace so that this call no longer works.

Sorry to say, embedding the DLL would be the best way around this. To get local variables when embedding the DLL, it should work if you can first make a separate SmartAssembly project for it, apply error reporting, and then embed this protected DLL to your main exe.

(Just a note: to make sure SmartAssembly uses the protected version of the DLL, you can add a MandatoryPath attribute to your saproj file)

Hope this helps!

dybalabj

Thanks, that took care of my issue quite nicely!

Once other problem I noticed, though. The DLL is signed with a strong name key. I can re-sign it and them embed the result in my main application with no problem. However, if I check "I want to add tamper protection", then I get a SecurityException that the "Assembly has been tampered" when I run the final application. This only happens if the original DLL is not present in the folder containing my executable (for instance, in an installed version). If the DLL I'm embedding is still present in the folder, the SecurityException does not occur.

Note that I can enable the "References Dynamic Proxy" and "I want to use string encoding with improved protection" options with no problem (with or without the original DLL). SmartAssembly indicates that both of these options also add some sort of tamper protection as well.

Jessica R

Hi Brandon,

I'm glad to hear that helped!

Regarding this new problem, there is unfortunately a known issue with embedding tamper protected assemblies as you are seeing.

Our tamper protection feature works by hooking into an assembly's static constructors and adding the 'StrongNameSignatureVerificationEx' windows API call to those methods (http://msdn.microsoft.com/en-us/library ... 9(v=vs.100).aspx). This verification call uses GetExecutingAssembly to find the physical file of the tamper protected asssembly and then verifies that file's signature against the signature in its manifest.

The issue with embedding a tamper protected assembly though is that a physical file for it does not actually exist. Thus, the GetExecutingAssembly call fails and the signature verification ultimately fails as well. (but keeping a copy of the embedded DLL in the folder would prevent this)

I'm afraid that to embed the assembly, you will need to protect it without the "I want to add tamper protection" option enabled

Please let me know if you have any further questions on this!