Embedded dependencies not being found

PeteJ

I am using SmartAssembly v6.9.0.114. The project uses 'dependency embedding' for a number of C# assemblies into the main exe.

If I launch the exe by double clicking on it - the exe starts up with no problems. If I create a shortcut to the exe - the exe starts up with no problems. If I copy the shortcut to the desktop - the exe starts up with no problem.

However, if I change the 'start in' folder in the shortcut to eg 'C:' (ie not the same folder as the exe) - the exe crashes on start up with a 'file not found' exception.

(If I build the exe without using SmartAssembly, ie no 'dependency embedding' - the exe runs OK in all of the above scenarios, it does not crash.)

Help....

PeteJ

I have had a reply from Redgate support. It might help someone in the future:-

Thanks very much for confirming that. I'm afraid this is likely the issue we've seen before which is logged internally as SA-1923. A bit more about this:

When you embed a managed dependency, that dependency is created and loaded into memory at runtime with no need for a physical copy of the dependency. When you embed a mixed-mode dependency, however, a physical copy of the file needs to be extracted to disk (usually to the temp folder) at runtime, and then this is what is loaded into memory.

When your application tries to load your embedded mixed-mode dependency, it will first make sure that it can locate that assembly's own dependencies. In most cases, those dependencies will be located alongside the main exe and the application would check there and successfully locate the dependencies.

This is normally the case, however, it seems that when .NET 4.6+ is used and if the .exe is invoked via a shortcut with "start in" set (or if it's invoked via it's Shell, such as double clicking a saved project file with the appropriate file association--which is the other case where we've seen this), this will fail. The problem is that the application extracts the mixed-mode embedded assembly to the temp folder, but expects its dependencies to be located in that same temp location and doesn't check the .exe's directory. Because its dependencies can't be found, the "could not load file or assembly... or one of its dependencies" error is thrown.

If you can also embed the dependencies of the mixed-mode assemblies then I think that should get around this, but assuming many are native assemblies, that unfortunately won't work as SmartAssembly can't embed native assemblies.