Application domain and managed ARX

[Anonymous]

Basic question, I guess, but need to be sure.

Since acdbmng.dll and acmng.dll are not in the GAC, the fact that I can install my ARX.net dll on any folder is because it will run on the same application domain as Autocad, where acdbmng.dll and acmng.dll are loaded at Autocad startup. Right?

[Anonymous]

Well, Application Domain is a .NET concept and is quite difficult to
understand. many (if not most) programmers do not directly deal with it. I
am not sure I understand it much, but here is some points.

1. Application Domain is about separating running managed code in minimum
memory space, so that the affect of possible error/crash to the working
process could be limited as much as possible. It is a memory space managed
by .NET runtime (CLR) to safe guard the memory use/abuse. It has nothing to
do with where the .NET dll (acdbmgd.dll/acmgd.dll) is loaded from (GAC or
not), nor it has anything to do with whether it is loaded at Acad startuo or
not.

2. A working operating system process (such as AutoCAD running process, or
an pure .NET exe process) may contain one or more Application Domains. It is
unlikely that your ARX .NET managed code runs in the same Application Domain
as AutoCAD (remember AppDomain is a .NET concept). AutoCAD exe is a process,
your ARX managed code runs in the same process, but in its own AppDomain.
And your managed code may create multiple AppDomains and runs in them.

3. ARX .NET API is mainly .NET wrapper of unmanaged code (so far, pure .NET
API may be available more and more for future Acad versions, who knows),
even with the AppDomain in place, it is still difficult to predict or
prevent Acad crash. Everyone who has done enough .NET programming must have
experienced this situation: your .NET application may run into an unhandled
exception, but your app does not die. Instead, .NET runtime displays a
message dialog box with 3 buttons. "Detail" bttuon allows you to see
exception stack infor; "Cancel" button shuts down your app immediately; and
"Continue" button keeps the app still alive (but if the app will work
normally from then on is another thing, depending on the nature of the
exception). The "Continue" option is mainly due to the AppDomain's
protection so that the app is still alive in spite of unhandled exception.
If it was an unmanaged app, your app would die immediately in such
situation. However, in ARX .NET app, some unhandled exception may cause this
.NET runtime message, some may simply crash Acad immediately. That is
because the ARX .NET code as the wrapper of unmanaged code, If the exception
is raised from the unmanaged code, the .NET AppDomain would not take effect
here.

Just my understanding, it may not be correct, though.


"sardanapalo" wrote in message news:[email protected]...
Basic question, I guess, but need to be sure.

Since acdbmng.dll and acmng.dll are not in the GAC, the fact that I can
install my ARX.net dll on any folder is because it will run on the same
application domain as Autocad, where acdbmng.dll and acmng.dll are loaded at
Autocad startup. Right?

[Anonymous]

If your app wasn't loaded into the same AppDomain as AutoCAD's clr host,
you wouldn't be able to use many of its APIs, so the answer is yes.

However, because of some obscure problems related to how AutoCAD
loads managed extension dlls, there are cases where they can fail if they
are not located in the same folder where acad.exe is.

--
http://www.caddzone.com

AcadXTabs: MDI Document Tabs for AutoCAD
Supporting AutoCAD 2000 through 2010

http://www.acadxtabs.com

Email: string.Format("{0}@{1}.com", "tonyt", "caddzone");

wrote in message news:[email protected]...
Basic question, I guess, but need to be sure.

Since acdbmng.dll and acmng.dll are not in the GAC, the fact that I can
install my ARX.net dll on any folder is because it will run on the same
application domain as Autocad, where acdbmng.dll and acmng.dll are loaded at
Autocad startup. Right?

[Anonymous]

Hello,

I am trying to call a function from another .dll via domain so that I can unload the .dll.

Originally my function used Assembly.Load. However I could not update the .dll file whilst within AutoCAD.

Public SharedSub InvokeAutoCADCommand(ByVal strCommandName AsString,

                                                         ByVal fullPathDllName AsString)

'Dim adevidence As Evidence = AppDomain.CurrentDomain.Evidence

Dim appDomSetup As New AppDomainSetup

Dim domain As AppDomain = AppDomain.CreateDomain("MyDomain", Nothing, appDomSetup)

'Dim assemblyBytes As Byte() = File.ReadAllBytes(fullPathDllName)

'Dim objAssembly As Assembly = Assembly.Load(assemblyBytes)

Dim objAssembly AsAssembly = domain.Load(fullPathDllName)

For Each objType AsTypeIn objAssembly.GetTypes()

If objType.IsClass = True Then

If objType.Name.ToLower = strCommandName.ToLower Then       

Dim ibaseObject AsObject = Activator.CreateInstance(objType)   

Dim arguments AsObject() = NewObject() {}           

Dim mi As MethodInfo = objType.GetMethod(strCommandName)

 mi.Invoke(ibaseObject, arguments)

'objType.InvokeMember(Nothing, Nothing, Nothing, Nothing, Nothing)

'objType.InvokeMember(strCommandName, BindingFlags.[Default] Or BindingFlags.InvokeMethod, Nothing, ibaseObject, arguments)

'objType.InvokeMember(strCommandName, BindingFlags.[Default] Or BindingFlags.InvokeMethod, Nothing, Nothing, arguments)      

Exit For   

End If   

End If

Next

AppDomain.Unload(domain)

End Sub

[philippe.leefsma]

Hi David,

Unless you have time to loose, I would discourage you trying to create your own AppDomain in order to make your AutoCAD dll unloadable. I personally tried to achieve that, and succeeded to some extent, as I was able to perform cross domain calls involving AutoCAD.Net API, however doing so, even using very simple APIs, just made AutoCAD unstable and reliably crashing at shutdown. I was told by the .Net development team that there are some globals variable in AutoCAD .Net core that would prevent cross domain workflow to work properly.

Concerning your code, you need to use "CreateInstanceAndUnwrap" if you want to perform cross domain calls. Also your current approach is wrong straight from the beginning: you have to realize that even accessing the existing types of an assembly from your command, which is run from the default domain, will cause that assembly to be loaded in that domain, and therefore making it unloadable. You need to use proxies for anything you want to access from the default domain to the one you created, you need to derive your custom proxy classes from  "MarshalByRefObject". I would suggest you take a look at some Microsoft documentation concerning "CreateInstanceAndUnwrap" and "MarshalByRefObject" if you are curious and not familiar with those concepts.

Regards,

Philippe.

 

[Anonymous]

Thank you very much for your reply,

I am beginning to come to the same conclusion as you have, it looks pretty difficult. I have done some investigation into "CreateInstanceAndUnwrap" and "MarshalByRefObject". However the only examples I could find are using a class which exists within the same dll so I can't find how to reference a class which is in the new dll.

If you have an example of what you did it would be most appreciated.

Kind Regards

David

[philippe.leefsma]

Here is my test project, it contains a test assembly to be loaded and the AcadDotNetLoader.

There are couple of commands that illustrates how to access existing AppDomains and loaded assemblies, some of this code was tricky to put together.

You can check how "DoNetLoad" command works and how I used the proxies to isolate the loaded dll types and methods from being loaded in the default appdomains.

If you can make progress in this area, you are welcome to share;)

Regards,

Philippe.