[luddet]

I'm developing an application which makes use of the AutoitX dll. In my Visual Studio 2005 C# project I add a reference to the AutoItX3.dll and all is fine and dandy.
Everything works on my development machine where I also have AutoIt installed.

Now I create a Visual Studio setup project and it detects the dependency of AutoItX3.dll and Interop.AutoItX3Lib.dll.

And this is where I get the problem. How should I set the settings for the reference and dependencies?
The defaults are:
Reference in main project->AutoItXLib - Isolated: False
Dependency in setup->AutoItX3.dll - Register: vsdrfDoNotRegister
Dependency in setup->Interop.AutoItX3Libb.dll - Register: vsdraDoNotRegister
If I leave them at the default values the application doesn't work on a computer that doesn't have autoit installed. I get this error message:
"Retrieving the COM class factory for component with CLSID {1A671297-FA74-4422-80FA-6C5D8CE4DE04} failed due to the following error: 80040154."

Now I change the settings to:
Dependency in setup->AutoItX3.dll - Register: vsdrfCOMSelfReg
Dependency in setup->Interop.AutoItX3Libb.dll - Register: vsdraCOMRelativePath
This will work even on a computer that doesn't have autoit installed, but it brings another problem instead.
If the computer has autoit installed and I then uninstall it after installing my application, my application stops working.

I'm assuming that this is because autoit removes the registration of the specific guid associated with the autoit dll when it is uninstalled without knowing that my application is using the same guid.

I hope I have made my problem clear enough.

So the big question is of course, how can I prevent this uninstallation problem from happening?

thanks
/luddet

This post has been edited by luddet: 07 February 2006 - 05:42 PM

[w0uter]

maby you could register it yourself evry time you start the application.

[luddet]

w0uter, on Feb 7 2006, 03:22 PM, said:

maby you could register it yourself evry time you start the application.

One would think there must be a simpler way...

[Richard Robertson]

Maybe you could call it as a DLL, not a COM? Then it wouldn't need to be registered, just in one of Windows' search directories. PATH/currentdir/etc

[luddet]

Icekirby1, on Feb 7 2006, 06:19 PM, said:

Maybe you could call it as a DLL, not a COM? Then it wouldn't need to be registered, just in one of Windows' search directories. PATH/currentdir/etc

That would probably work. But I don't know how to do that. Do you? Or anyone else here?

[Zach]

luddet, on Feb 7 2006, 03:50 PM, said:

One would think there must be a simpler way...

It is not a bad idea to register you files every time your application starts irregardless - depending on how many external, 3rd party dlls or ocxs you are using (if any other than AutoIt) - some companies/individuals have a bad habit of when they do updates not changing the CLSID - though the component might have breaking changes in it.

By re-registering your needed files at run time - you insure that if that situation does happen - you at least have the files you need when the program started

[luddet]

Zach, on Feb 8 2006, 06:21 AM, said:

It is not a bad idea to register you files every time your application starts irregardless - depending on how many external, 3rd party dlls or ocxs you are using (if any other than AutoIt) - some companies/individuals have a bad habit of when they do updates not changing the CLSID - though the component might have breaking changes in it.

By re-registering your needed files at run time - you insure that if that situation does happen - you at least have the files you need when the program started

How would I do this? And could there be any drawbacks?

I was also thinking about perhaps using [DllImport("AutoItx3.dll")] in some way, but I don't know how to import a whole class this way.

[ramadash]

I think you forget to add the reference to the autoit type library. I add the same (or similar) problem when making my .net autoitx wrapper. In your description you are only adding one reference to autoitx, wich if it is true, is not enough.

first of all you need to add->reference->projects, the browse to your autoit dll (wich is probably what you already done). Once that is done, vs.net will create Interop.Autoit3x.dll. when this is done your need to add another reference but this time in add->reference->COM, select browse, and reference your newly created Interop.Autoitx.dll file. This worked for me, and once vs.net register it you will see autoit type library on the list when you click on COM.

[flaxcrack]

luddet, on Feb 7 2006, 11:41 AM, said:

I'm developing an application which makes use of the AutoitX dll. In my Visual Studio 2005 C# project I add a reference to the AutoItX3.dll and all is fine and dandy.
Everything works on my development machine where I also have AutoIt installed.

Now I create a Visual Studio setup project and it detects the dependency of AutoItX3.dll and Interop.AutoItX3Lib.dll.

And this is where I get the problem. How should I set the settings for the reference and dependencies?
The defaults are:
Reference in main project->AutoItXLib - Isolated: False
Dependency in setup->AutoItX3.dll - Register: vsdrfDoNotRegister
Dependency in setup->Interop.AutoItX3Libb.dll - Register: vsdraDoNotRegister
If I leave them at the default values the application doesn't work on a computer that doesn't have autoit installed. I get this error message:
"Retrieving the COM class factory for component with CLSID {1A671297-FA74-4422-80FA-6C5D8CE4DE04} failed due to the following error: 80040154."

Now I change the settings to:
Dependency in setup->AutoItX3.dll - Register: vsdrfCOMSelfReg
Dependency in setup->Interop.AutoItX3Libb.dll - Register: vsdraCOMRelativePath
This will work even on a computer that doesn't have autoit installed, but it brings another problem instead.
If the computer has autoit installed and I then uninstall it after installing my application, my application stops working.

I'm assuming that this is because autoit removes the registration of the specific guid associated with the autoit dll when it is uninstalled without knowing that my application is using the same guid.

I hope I have made my problem clear enough.

So the big question is of course, how can I prevent this uninstallation problem from happening?

thanks
/luddet

Did you make sure that the property of the Local Copy of the Reference read as true. I have gotten it to work. See my screen shot.

[flaxcrack]

flaxcrack, on Mar 13 2006, 11:21 AM, said:

Did you make sure that the property of the Local Copy of the Reference read as true. I have gotten it to work. See my screen shot.

I'm sure you also want it to be bundeled for deployment sake too. What is your method of deployment?

[darkxiii_ndp]

Using RegFree COM, you can deploy an application that uses a COM component without registering it on the user's machine, thus avoiding the notorius collection of problems commonly referred to as "DLL Hell." RegFree COM even allows you to run multiple versions of a COM component on the same machine.

RegFree COM works by automatically generating a manifest from the COM component's type library and component registration on the developer's machine. Therefore, while it is not required to install the component on the end users' machines, a copy must be registered on the developer's machine.

To enable use of RegFree COM, all COM components referenced in Visual Studio 2005 now have a new Isolated property. If you set Isolated to true, the component can be deployed through ClickOnce, and Visual Studio 2005 will automatically do all the work to deploy the COM component onto the target machine (without needing to register it on the target machine).

http://img432.imageshack.us/img432/9119/1237iy.gif

[Insolence]

When I try to set "Isolated" to true, I get this exception:

Quote

"System.ArgumentNullException was unhandled
Message="Value cannot be null.\r\nParameter name: activationContext"
Source="mscorlib"
ParamName="activationContext"
StackTrace:
at System.Runtime.Hosting.ApplicationActivator.CreateInstance(ActivationContext activationContext, String[]activationCustomData)
at System.Runtime.Hosting.ApplicationActivator.CreateInstance(ActivationContext activationContext)
at Microsoft.VisualStudio.HostingProcess.HostProc.RunUsersAssemblyDebugInZone()
at System.Threading.ThreadHelper.ThreadStart_Context(Object state)
at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
at System.Threading.ThreadHelper.ThreadStart()"

EDIT:
I don't know what I changed, but now it at least runs fine with debugging, but when I release and execute it without a I get an unhandled exception.

This post has been edited by Insolence: 10 December 2006 - 09:55 PM

[daluu]

See also related post on how to use AutoIt as C++ DLL and not a COM DLL

http://www.autoitscript.com/forum/index.php?showtopic=72905

This post has been edited by daluu: 15 September 2008 - 05:26 AM

[jcddcjjcd]

The previous link refers to a post of mine. I can see where you are coming from, the use of the Autoit COM object is very appealing but I never got it to work in a satisfactory way when deploying to other machines. The RegFree approach does not work well for AutoIt and when you read all the MS documentation about RegFree you can see that is not a solution for every case. That is why I took the trouble to provide the examples of using all of the dll functions via C# calls.
Thanks to AutoIt for providing the dll version and I hope that always will be so.
Regards,
John.

[amokoura]

jcddcjjcd, on Sep 29 2008, 08:19 AM, said:

...
The RegFree approach does not work well for AutoIt..
...

Does this help at all?: RegFreeCOM Au3X Example, Use RegFree to Solve DLL Hell, Even With COM Clients

[jcddcjjcd]

amokoura, on Sep 29 2008, 02:28 AM, said:

Does this help at all?: RegFreeCOM Au3X Example, Use RegFree to Solve DLL Hell, Even With COM Clients

It is true that the example above does work, I tried it way back and again today. It would be great if the source files were made available so we can see how it was done. I spent a couple of days with settings in VS but never got it to work reliably in my apps. The source may provide the answer. Perhaps the manifest was made manually rather than using the MS suggestion of letting VS do the work.
Regards,
John.

[jcddcjjcd]

Well I looked at the source and it just shows the standard way of doing it. Very simple really. I still get problems though when I use it in my own ClickOnce deployments. Particularly errors stating that the assemblies need to be strong signed. Using the dll with dllImport still gives the same functionality but with no deployment issues.
Regards,
John.

[amokoura]

Thank you for sharing your experiences.
I was really attracted to the regree solution and was about to use it.
Seems that the best approach is to use the plain dll.
At least then I wouldn't have to struggle with the same problems as you have been fighting with..