views:

211

answers:

4

Hello,

The software company I'm working for builds software for schools, and so our client machines are usually locked down in such a way it makes it pretty impossible for us to install anything on it.

Our old system is primarily based on a (very large) MS Access project and so it gets around the access problems by just running from a local folder.

I've been given the task of redeveloping some of the system into c# .NET - however it would be nice in the interim stages to have the ability to have the access project fire .NET things off.

I have played around with com interops for a few hours today but afaik the only way to make these work is to register them with RegAsm.exe - and unfortunately this isn't an option in the client environments.

I've tried GetObject / CreateObject but neither work when referencing a dll or tlb file, is there any other way this could be achieved?

The ideal solution would be to put the com interop dll in the same directory as the Access project.

And yes, before anyone says it, I know MS Access is evil and only suited for very small projects - but I only arrived here 4 months ago...

Marlon

A: 

you say you can't install anything, but could you write the necessary stuff into the registry yourself? I think that all regasm does is write all some stuff to the registry, so you could effectively do that from your VB code on startup if its not there and then you might be able to load the interop assembly.

you can use a tool like process monitor to see what gets written to the registry when you run regasm.

I'd make sure you are using the -codebase switch and explicitly defining Guids for your interfaces and classes for the com wrappers as well. not doing so caused me no end of issues trying to get com wrapped .net dlls to work properly

Sam Holder
On XP and later COM objects can be registered in the user portion of the registry (HKEY_CURRENT_USER) and you will probably have permissions to write there from the user account. You probably won't have permissions to register the COM objects globally (in HKEY_LOCAL_MACHINE). You could convert what regasm does from HKLM into HKCU
MarkJ
+2  A: 

You could host the CLR inside Access:

Add a reference to mscoree (Probably C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\mscoree.tlb)

Sub Main()
    Dim CORHost As New mscoree.CorRuntimeHost
    Dim Domain As Object
    Dim AssemblyFilename As String
    Dim Classname As String
    Dim Result As Object

    AssemblyFilename = "mscorlib"
    Classname = "System.Collections.ArrayList"

    CORHost.Start
    CORHost.CurrentDomain Domain
    Set Result = Domain.CreateInstance(AssemblyFilename, Classname).Unwrap()

    Result.Add "test"
    MsgBox Result.Count
End Sub

This bypasses the need to use the registry. The down side of this is you have to use late binding with your objects.

You can also add a reference to mscorlib.tlb to get type information for the AppDomain class and others.

Foole
Hello, Thanks for your post, it sounds very promising. I've just tested it out but I get a 'Type Mismatch' error when passing the Domain object to the CORHost.CurrentDomain. I looked at the interface specs and it passes a pointer not an object - will vb6 care about that? (sorry, my vb6 skills are limited).
Marlon
If you still get the type mismatch with my updated code, try adding a reference to mscorlib.tlb and declaring Domain as an AppDomain.
Foole
Hello, I still got a Type Mismatch with that code, I also tried adding a reference to mscorlib.tlb but there doesn't seem to be a definition for "AppDomain" in there. Closest thing is AppDomainManager or AppDomainSetup.
Marlon
That should only be the case if you have put "New" in there.
Foole
ah sorry - yep that worked. thank you very much for this solution.
Marlon
+3  A: 

As long as your client systems are Windows XP or later then you have the option of using Registration Free COM. This replaces the need to registry the COM components using regasm (or regsvr32 for native COM servers) in the system registry with XML configuration manifest files.

With this you still use the standard CreateObject calls to create your objects.

shf301
I had a quick read through that tutorial, the only potential concern is because we're working with an MS Access project, no VB6.exe is compiled so I don't think I could compile the manifest with the project. I'll research this further though.
Marlon
You would probably need to put the manifest with the Access main executable. This is somewhat risky, and you may not have permissions to do it.
MarkJ
You can load process manifest at run-time -- http://msdn.microsoft.com/en-us/library/aa375259(VS.85).aspx
wqw
A: 

If been using .Net DLLs from my VB6 projects by using manifests. The only requirement is the VB6 executable and .Net DLL be in the same folder.

I'm using UMMM tool to automatically create the dependency entry in the application manifest.

You can use ActCtx.Manifest property to dynamicly load a proper manifest for reg free access to .Net interop coclasses.

wqw