I am trying to use MEF, however, I noticed that it will crash if a .dll with the wrong interface is present in the directory that is being currently used. Is there any way to correct/avoid this issue, beyond simply only allowing the correct .dlls to be present in the plugin folder?
EDIT
Error is:
Unable to load one or more of the requested types. Retrieve the LoaderExceptions property for more information.
Related
I'm trying to build a game using Monogame. Monogame uses its own bunch of DLLs. However inside one of those DLLs is a dependency on another DLL (which could potentially not exist as it was not installed).
More specifically when trying to utilize a method/class of Monogame's DLLs
GamePad.GetState(PlayerIndex.One).Buttons.Back
This error is produced:
Unable to load DLL 'xinput1_3.dll': The specified module could not be found. (Exception from HRESULT: 0x8007007E)
The fix for this error isn't difficult. The user needs to install the correct system requirements.
How do I tell this to the user from the front end? My aim is to inform the user that 'Gamepad controllers are disabled for this because xxx is not installed on your system', while carrying on running the game - as gamepads are optional.
Is there a way I could have caught this issue (i.e. is there a way I could have checked to see if this DLL exists - without being very specific of its location/filepath) before attempting to utilize the method/class?
Is having a try-catch block around the whole application the best approach?
Are there better ways to handling the (common?) 'Unable to load DLL' cases?
My main goal is to ignore any DLL dependency issues as I plan to distribute this game without installers. Plus any missing non-game-breaking DLLs should just be ignored.
One solution could be to programmatically check all system folders for the required dlls during startup and alert user if they are missing.
EDIT: There is a better solution, check using LoadLibrary() function, Check if a DLL is present in the system
You can check list of all .DLLs you need before running the app.
Of course you can alays rely on try and catch for DLLs which you never knew.
I've looked at this question:PrecompileBeforePublish using Msbuild, but it doesn't fully address my issue. In trying to use PrecompileBeforePublish=true for our build of a web application, I am getting an error and build failure when MSBuild encounters a referenced DLL that is not a managed code assembly (it is a 3d party .dll we use for data access). If I set PrecompileBeforePublish=false, or just take the property out of the publish file, the build completes as expected.
My question is whether there are any attributes for this property that can be used to avoid this particular issue, or whether I am just stuck with the simple binary true/false value of the property. I suspect the latter.
To clarify per Sayed's question: I was attempting to precompile the application, so did in fact have PrecompileBeforePublish set to true in my publish profile that I am using to create the deployment package.
We are referencing some .dll's for data access that are compiled as unmanaged code. I suspect what is happening is that when we precompile, since our solution is managed, it (the build process) barfs when it encounters a referenced .dll that is unmanaged. The error we get is: "ASPNETCOMPILER: error ASPCONFIG: Could not load file or assembly 'xxx' or one of its dependencies. An attempt was made to load a program with an incorrect format.
The background here is, I am developing a plugin for a CMS which is loaded via reflection from an external assembly. I want to embed some javascript and CSS files into my assembly so that I can load those files inside the CMS.
Ordinarily, you'd use Page.ClientScript.GetWebResourceUrl(Type type, string resourceName) and the resulting URL points to WebResource.axd, whose job it is to find the correct assembly, locate the correct resource and stream it back to the client.
This works fine if the assembly is already loaded as part of your application (e.g. it exists in your bin folder), but in this case it won't work because my assembly is only ever loaded via reflection (i.e. Assembly.Load()) from an external directory. The WebResource handler won't be able to find the assembly and so requests of this type will always result in a 404.
My question is, is there an accepted and well-trodden way of doing what I'm trying to achieve here or am I going to have to roll my own? Bear in mind, simply putting the assembly in the bin folder is not an option here.
I've tried google and searching here and I can find people with the same problem I'm experiencing, but no solutions as yet.
Oh, I should add, I'm running on .NET 4.0
You should load all of your plugin assemblies eagerly using BuildManager's AddReferencedAssembly method.
This can be achieved at application start by utilizing the PreApplicationStartMethodAttribute.
Then whenever you need to discover your types use GetReferencedAssemblies.
When would the following message be shown?
Error 1 Unknown build error, 'Cannot resolve dependency to assembly 'Infragistics2.Win.v10.3, Version=10.3.20103.2015, Culture=neutral, PublicKeyToken=7dd5c3163f2cd0cb' because it has not been preloaded. When using the ReflectionOnly APIs, dependent assemblies must be pre-loaded or loaded on demand through the ReflectionOnlyAssemblyResolve event.'
I have added few DLLs to an existing working project. I know it's difficult to pin point the reason without the details on the code-base, but what I would like to know the general cause for such error messages to appear?
Note: Just created a fresh WPF project and added the bunch of new DLLs. The issue is present there also. Therefore, it's highly likely that the issue is due to organization and content of the DLLs.
This can happen if your xaml file statically references a view model class and that view model class has a dependency which may not be recognised as missing in the xaml file. You will need to add that dependency to the offending project. Because it is referenced in the xaml file compile time errors aren't clear on the source of the problem.
Proper version of Infragistics DLL was missing and adding it resolved the issue.
Note: The problem is too localized and hence this solution is useful at local system only.
I am getting an exception from my code while designing in Blend 4.
I have narrowed the issue down to loading a specific library. Other libraries can be loaded fine, just this one fails. So, for this code:
var a = Assembly.Load("lib1");
var b = Assembly.Load("lib2");
Line two will throw an exception: Could not load file or assembly 'lib2' or one of its dependencies. The system cannot find the file specified.
If the same code is run outside of Blend, it does not throw. Both assemblies appear to be referenced the same way in the project, and both are marked Copy Local.
Any suggestions on how to troubleshoot this issue?
At design time Blend copies your assemblies to a temporary folder other than your output folder so things can behave differently than when you run the program normally. Blend also requires the "Any CPU" configuration for design time so if you run "x86" normally you can get different results simply because of that.
But Blend itself is a managed program like any other and to diagnose the problem in detail you can crack open the Fusion Log Viewer to see assembly binding errors to try to find out what is going wrong. Presumably the library itself is where it ought to be (in Blend's temporary folder) but one of its indirect dependencies is not being found. By using the log viewer with sufficient detail, you should be able to see the specific binding failure that is causing the problem.
Here is a link:
Fuslogvw.exe (Assembly Binding Log Viewer)