First of all i am a membr of this forum under the name 'simon_may' but could not log in for some reason so I rejoined as 'simon_may1' in order to post this question.
The situation is this. We have a VB6 .exe that calls a .Net Com interop dll. This dll calls some CSLA business logic. A BusinessBase class which in turn calls a data access object using a object factory attribute. This all works fine in a .Net application but when called by the VB6 .exe it fails with the following exception [DataPortal.fetch failed (Factory type or assembly could not be loaded)]
We have stepped through the code and find that in the method FactoryLoader contained in Csla.Server.FactoryDataPortal.cs that the _factoryLoader field is not null therefore it does not attempt to read the CslaObjectFactoryLoader configuration setting.
If the ObjectFactory attribute is set to the full assembly name the same error occurs
I am hoping that someone might have an idea as to why we are not seeing the expected behaviour or ideas as to how we might attack this further.
Regards
Simon
The second .NET book I ever wrote was on COM interop, around 2002. Sadly I doubt you could find that book anymore, but it would have the answer :)
Also sadly, I haven't given COM interop all that much though since 2002, so what I'm about to say may be only partially correct.
As I recall, when a .NET assembly is loaded by a VB6 program, the .NET assembly path is the folder that contains the VB6 EXE. As a result, your .NET assemblies need to be in the same folder as the EXE that is launching them.
The rules are different if the VB6 code is running in COM+.
And I seem to remember some complexities around COM registry file locations vs actual disk locations, but I think this is because COM only allows you to register a DLL one time, therefore in one location, but the actual runtime assembly path is always the location of the VB6 EXE.
All that said, I also remember that around 2002 or 2003 the Windows OS added "side by side" COM registration, allowing a COM app to load other COM DLLs from a local folder without having those DLLs registered in the main OS registry. I didn't really care, and never looked into this - I only remember it, because the thought occurred to me at the time that if this feature had existed before .NET came along, then perhaps VB6 wouldn't have died, because this feature makes it as easy to deploy COM apps as it is to deploy .NET apps...
Hi Rocky thank you for looking at this.
We have run this with all assemblies in the same folder as the VB6 .exe. The COM interop dll is registered correctly with reg.asm.
We have built a .Net test app that executes with no errors or problems and is also in the same folder as the VB6 .exe,
From the VB6 IDE we have debugged into the .Net CSLA code and have found the unexpected behaviour.
We have stepped through the code and find that in the method FactoryLoader contained in Csla.Server.FactoryDataPortal.cs that the _factoryLoader field is not null therefore it does not attempt to read the CslaObjectFactoryLoader configuration setting.
If the ObjectFactory attribute, in the business object is set to the full assembly name the same error occur. I.e the CSLA default FactoryKiader is also failing
Does anybody know if this could be related to user permissions, windows UAC, etc. All ideas and work arounds are welcome, as we are in serious contractual/time trouble.
Simon
Fixed
If using a COM (Unmanaged executable) to call a .NET assembly then the configuration file must be renamed to the name of the Unmanaged executable (e.g. MyVB6App.exe.config).
The simplest of mistakes can be the hardest to find.
Karl
That sounds familiar now that you say it. I am glad you figured it out!
Copyright (c) Marimer LLC