Compilation project - MySql.Data, version=6.8.3.0 - compilation

I have a problem with the program, when compiled and threw on another system that displays my problem running. I installed net connector, and it did not work.
Could not load file or assembly 'MySql.Data, version = 6.8.3.0, Culture = neutral, publickey token = c5687fc88969c44d' or one of its dependencies. You can not find the file specified.
http://i.stack.imgur.com/LRZhs.jpg
I recorded the whole process.
http://youtu.be/kYhAiJ1BhCg

Check if "'MySql.Data, version = 6.8.3.0, Culture = neutral, publickey token = c5687fc88969c44d' or one of its dependencies" assembly is in GAC (c:\WINDOWS\assembly\GAC_MSIL) And if it`s not, add this assembly. I think this will solve your issue.

Related

How to make an unmanaged CLR Host load its AppDomainManager thorugh IHostAssemblyStore::ProvideAssembly()?

I am building an unmanaged CLR Host and have a very specific question regarding the loading of my managed AppDomainManager assembly via an unmanaged IHostAssemblyStore implementation. Specifically I can't seem to get the CLR to load my AppDomainManager assembly through my IHostAssemblyManager component.
I specify my AppDomain Manager type on the ICLRControl interface as I am supposed to:
...
hr = pCLRControl ->SetAppDomainManagerType(L"MyManagedAppDomainManager, Version=1.0.0.0, PublicKeyToken=9ab418b2d23c1abd, ProcessorArchitecture=MSIL",
L" MyManagedAppDomainManager.MyAppDomainManager");
...
If I include this type in the list of assemblies returned by IHostAssemblyManager::GetNonHostStoreAsemblies(), the CLR looks for the assembly/type in my application directory, finds it and loads it no problem.
However, if I remove this type from the non-host store assemblies list, the above line throws a C++ EEFileLoadException error. I don't expect this. I expect my IHostAssemlbyStore::ProvideAssembly() implementation to get called to provide the assembly, and it doesn't.
Note that in the first case (where I include the assembly in the non-host store assemblies list), once my AppDomainManager assembly loads, all other assemblies not specified in the list are redirected to my IHostAssemblyStore::ProvideAssembly() implementation as they are supposed to be. I just can't seem to get the CLR to call this method for the AppDomainManager assembly itself.
Does anybody know how to get an unmanaged CLR Host to load the AppDomainManager assembly through IHostAssemblyStore::ProvideAssembly()?
Update:
I found the issue: I was missing the "Culture" portion of the assembly name:
hr = pCLRControl ->SetAppDomainManagerType(L"MyManagedAppDomainManager, Version=1.0.0.0, PublicKeyToken=9ab418b2d23c1abd, Culture=nueutral, ProcessorArchitecture=MSIL",
L" MyManagedAppDomainManager.MyAppDomainManager");
I found this by turning Fusion Log on.
Hope this helps someone else.
Rod

LoadLibraryExW() fails, last error is ERROR_MOD_NOT_FOUND, but no missing dependencies?

A customer is using our dll which is creating a child process which uses an open source library, which ultimately fails because of a call to LoadLibraryExW(), the last error returned is ERROR_MOD_NOT_FOUND. This occurs on WinXP 32-bit, but not on other machines. But we know the correct set of dependencies is installed and even in the same directory.
So we thought naturally, to use Dependency Walker to look for what dependency is missing on that particular machine. Unfortunately it doesn't show any missing, just some delay-load warnings that aren't direct dependencies of the library. In my experience using depends.exe has always revealed what the missing dependency is.
So at this point I've pulled my hair out trying to understand why I'm getting ERROR_MOD_NOT_FOUND if all of the library's dependencies are there? The only other thing that makes this machine unique is it's very secure because it's used by the government, but if we were having an access/permissions issue I'd expect a different type of error code.
I've built a small Win32 executable that does nothing but call LoadLibraryExW() on the said library, when it's run from the same directory as the library is located, it loads the library without issue, on the customer's problematic machine.
One thing is that our product is an ActiveX plugin which launches a child process, the child process calls into the 3rd party library, the 3rd party library has the problematic LoadLibraryExW() call. So maybe why it's failing is the context it's running (e.g. from the browser)?
Use the Profiling option of the Dependency Walker on your application. Possibly the library is trying to resolve some APIs dynamically (using LoadLibrary/GetProcAddress) and this won't show up in the static dependencies.
The best way is to use loader snaps. Basically you use gflags.exe (which is included with windbg) to enable loader snaps; then, run the process with the debugger attached. Loader snaps will enable the loader to print out dbg messages of the process and it will print the failures.
gflags.exe -i yourcode.exe +sls
windbg yourcode.exe
Your dependencies might be present on the system but they could be in a folder that is not part of the search order during LoadLibraryExW().
A SetDllDirectory() or AddDllDirectory() call would ensure that the folder containing the dependencies is searched during the LoadLibraryExW() call

Problems referencing com dlls in vs 2010

I'm running a 32 bit ver of win7 in a vm. I am trying to reference 5 com dlls (VB6) in my .net project. These dlls (and their dependencies) are registered ok since I can use them natively as they form a part of another app and that app is working fine.
I try to set a reference to any of them directly in vs and I get the error message - Library not registered (Exception from HRESULT: 0x8002801D (TYPE_E_LIBNOTREGISTERED)).
However, if I set a reference to another com component (which I don't want to reference but which in turn does reference these libs) I find that the references to these com dlls (which I do want to reference) gets set correctly in vs. I then just need to remove the ref to the unwanted dll and everything seems to be good to go.
If I look at the GUID and version details of one of the successfully referenced component, they appear to be the same as the GUID and version that appears in the caption of the error form, when I unsuccessfully try and set a reference to the same component directly.
BTW I have tried repairing the VS installation to no avail
I was wondering if someone could explain what I am doing wrong.
EDIT: Follow-up following Hans suggestion
So I ran
tlbimp mylib.dll
and it returned a TI1006 error - Output would overwrite the input file. So following suggestions found, I then issued
tlbimp mylib.dll /OUT:interop.mylib.dll
and this then returned the error
TlbImp : warning TI3011 : Type library importer has encountered an interface not derived from IUnknown: '_HiddenInterface'. The interface is skipped.
TlbImp : error TI1033 : Cannot find type 'ADODB._Recordset_Deprecated' in 'ADODB, Version=7.0.3300.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'. There could be a mismatch between the referenced assembly and the type library.
But I'm not sure if this is a red herring since this lib could be referenced when successfully referencing the different higher level dll. I have tried with a dll which doesn't reference ADODB and that seems to work using tlbimp. So, e.g.
tlbimp myNONADODBlib.dll /OUT:interop.myNONADODBlib.dll
works from the commandline. However
tlbimp myNONADODBlib.dll
still generates the error TI1006 - output file will overwrite input file, and I cannot reference this into my .net project
EDIT:
There seems to be a problem with ADO and Win7 SP1. http://support.microsoft.com/kb/2517589 which would account for the deprecated error message (TI1033) I was getting, but not why VS was failing to create a CCW for the dll I can manually create a CCW via tlbimp.
EDIT (12/03/28 10:40):
So I have rebuilt the com dll with the suggested tlb. I can now successfully run
tlbimp mylib.dll
without getting any error messages and it appears to complete successfully. However, when I try and add a reference to that dll in VS, I still get the same original error message ( Library not registered (Exception from HRESULT: 0x8002801D (TYPE_E_LIBNOTREGISTERED))). I have checked the registry and the registration looks ok i.e. it is pointing to the correct path - I'm wondering if it is a permissions-type issue - but I am running vs as admin.
EDIT (12/03/28 10:15):
So I ended up creating a new completely new vm with the same environment - and it worked ok. So I've no idea what is going on other than some registry corruption perhaps!
Many thx
Simon.
You need to use REGTLIB.exe to register the type library of the DLLs.
Type library registration is separate from component registration - the type library supports the introspection/type explorer functionality, and isn't usually required for running a precompiled application, though it may be required for compilation.

NHibernate UnableToLoadProxyFactoryFactoryException

I have a similar problem to the one posted
here.
Here's my code (c#):
var nHConfig = new Configuration().Configure();
var sessionFactory = nHConfig.BuildSessionFactory();
The actual configuration is detailed in an App.config file:
<session-factory>
...
<property name="proxyfactory.factory_class">
NHibernate.ByteCode.Castle.ProxyFactoryFactory, NHibernate.ByteCode.Castle
</property>
...
</session-factory>
I am referencing both NHibernate.dll and NHibernate.ByteCode.Castle.dll.
Here's the error I get:
failed: NHibernate.Bytecode.UnableToLoadProxyFactoryFactoryException : Unable to load type 'NNHibernate.ByteCode.Castle.ProxyFactoryFactory, NHibernate.ByteCode.Castle' during configuration of proxy factory class.
Here is the solution accepted in the aforementioned post (answer given by Kevin Crowell):
This problem occurs when NHibernate.ByteCode.Castle.dll was built with a different target platform as your project. To test this, change your program target platform from one or more of the following:
x64 to x86
x86 to x64
"Any CPU" to x86
"Any CPU" to x64
If any of those solve your problem, then you know that you just need to synchronize the DLL and your target platform.
My problem is this -
When I try running the application after changing the target platform, Visual Studio raises the following error:
Error while trying to run project. Cannot start debugging. The assembly to be debugged was built with a platform incompatible with the current system.
Any ideas what I might be doing wrong, and what I can do to correct or work around the problem?
Many thanks!
Referencing NHibernate.ByteCode.Castle.dll from your project is not necessary since it is a dependency resolved runtime. You must ensure that the assebly is present in the private bin path of your application ( near the executable for a desktop app, in the /bin path for a web application ) and that the other dependencies of that assembly are present too.
As an additional reference, from version 3.2.0 GA there is a default proxy factory pointing to an internal LinFu proxy, see this JIRA:
https://nhibernate.jira.com/browse/NH-2586
so if you have any special needing to use the castle proxies, yoo can completely avoid the configuration of the proxy factory.

Migration issue from vs2008 to vs2010

I have Solution in vs2008 with framework 2.0. Now I migrated solution to vs2010 .net framework 2, and it works.
Here problem occur when I changed framework from 2.0 to 4.0, after that when I run application(win-form) it throws error on resource file saying
"System.IO.FileNotFoundException: Could not load file or assembly
'SpServer.resources, Version=1.0.0.2, Culture=en-US,
PublicKeyToken=null' or one of its dependencies. The system cannot
find the file specified. File name: 'SpServer.resources,
Version=1.0.0.2, Culture=en-US, PublicKeyToken=null' --->
System.IO.FileNotFoundException: Could not load file or assembly
'...SpServer.resources.dll' or one of its dependencies. The system
cannot find the file specified.
I have not made any extra resource file, and assembly was not satellite assembly too before if there is error. Please let me know how to sort out this issue.
From MSDN:
Beginning with the .NET Framework 4, the AssemblyResolve event is raised for satellite assemblies. This change affects an event handler that was written for an earlier version of the .NET Framework, if the handler tries to resolve all assembly load requests. Event handlers that ignore assemblies they do not recognize are not affected by this change: They return null, and normal fallback mechanisms are followed.
Please also see my answer to this question.

Resources