what does this warning mean?

[Anonymous]

I'm new to dotnet and am tasked to modify an existing program so have to do
some quick learning...

I can build and run the app but get the following warnins in the errorlist
window
"Path to dll .dll" does not contain any types that can be unregistered for
COM Interop.
"Path to dll .dll" does not contain any types that can be registered for COM
Interop.

there is a reference to acad type library in the project so i assume it's
using interop as I see lines like
m_acadDoc.Utility.GetString

does a line like that indicate i'm using autocad com api as opposed to
managed .net api?

what would the equivalent line look like in managed .net api?

the examples i've seen and test apps i've started playing with previously
just referenced acmdg.dll and acdbmgd

in this one the refs are: acmgd, autoCad, and axdbLib

Is that an indication that com interop is being used?

In general if I look at a strange piece of code how do i know if it's com
interop versus .net api?

Thanks for any info

mark

[Anonymous]

Visit the online documentation (I just can't believe they're playing that
game --- not making it available offline), and you'll find a lot of basic
examples that are oriented towards newcomers, including ones that show how
to get input using the managed API:

http://docs.autodesk.com/ACD/2010/ENU/AutoCAD%20.NET%20Developer's%20Guide/index.html


--
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");

"mp" wrote in message
news:6293229@discussion.autodesk.com...
I'm new to dotnet and am tasked to modify an existing program so have to do
some quick learning...

I can build and run the app but get the following warnins in the errorlist
window
"Path to dll .dll" does not contain any types that can be unregistered for
COM Interop.
"Path to dll .dll" does not contain any types that can be registered for COM
Interop.

there is a reference to acad type library in the project so i assume it's
using interop as I see lines like
m_acadDoc.Utility.GetString

does a line like that indicate i'm using autocad com api as opposed to
managed .net api?

what would the equivalent line look like in managed .net api?

the examples i've seen and test apps i've started playing with previously
just referenced acmdg.dll and acdbmgd

in this one the refs are: acmgd, autoCad, and axdbLib

Is that an indication that com interop is being used?

In general if I look at a strange piece of code how do i know if it's com
interop versus .net api?

Thanks for any info

mark

[Anonymous]

As to your specific question, the warning means your project settings are
set to register your assembly or executable for COM. You only do that if you
are building a COM server, not a client (which is what you have). I'm not
familiar with where it is in VB.NET, but somewhere in your project's
properties, you'll find a setting that controls this.

If a project uses AutoCAD COM APIs, it will reference AutoCAD and AxDbLib.
The assemblies whose names contain 'mgd' are managed assemblies.

--
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");

"mp" wrote in message
news:6293229@discussion.autodesk.com...
I'm new to dotnet and am tasked to modify an existing program so have to do
some quick learning...

I can build and run the app but get the following warnins in the errorlist
window
"Path to dll .dll" does not contain any types that can be unregistered for
COM Interop.
"Path to dll .dll" does not contain any types that can be registered for COM
Interop.

there is a reference to acad type library in the project so i assume it's
using interop as I see lines like
m_acadDoc.Utility.GetString

does a line like that indicate i'm using autocad com api as opposed to
managed .net api?

what would the equivalent line look like in managed .net api?

the examples i've seen and test apps i've started playing with previously
just referenced acmdg.dll and acdbmgd

in this one the refs are: acmgd, autoCad, and axdbLib

Is that an indication that com interop is being used?

In general if I look at a strange piece of code how do i know if it's com
interop versus .net api?

Thanks for any info

mark

[Anonymous]

Hi Tony,
Thanks for your response. what would be an example of a com server, in other
words, what kind of application would need to be a com server?
this app just creates some commands in acad that read and write some acad
objects and writes some xdata to some objects. So I could move that
functionality to c# managed api right? If I went that route, what would the
"get acad' lines look like, as opposed to the current:
m_AcadApp = TryCast(GetObject(, "AutoCAD.Application"), AcadApplication)

I'm guessing it's something like the following:

C#

using Autodesk.AutoCAD.Runtime;
using Autodesk.AutoCAD.ApplicationServices;
using Autodesk.AutoCAD.DatabaseServices;
...

m_AcadApp = Application

so "application" automatically becomes the acad app in the using scope?
right?



Thanks

mark




"Tony Tanzillo" wrote in message
news:6293324@discussion.autodesk.com...
As to your specific question, the warning means your project settings are
set to register your assembly or executable for COM. You only do that if you
are building a COM server, not a client (which is what you have). I'm not
familiar with where it is in VB.NET, but somewhere in your project's
properties, you'll find a setting that controls this. \

If a project uses AutoCAD COM APIs, it will reference AutoCAD and AxDbLib.

right, those two are refed, so if i change to net api i can lose those and
just ref in acmgd and axdbmgd right?
then what
The assemblies whose names contain 'mgd' are managed assemblies.

--
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");

"mp" wrote in message
news:6293229@discussion.autodesk.com...
I'm new to dotnet and am tasked to modify an existing program so have to do
some quick learning...

snip

m_acadDoc.Utility.GetString

does a line like that indicate i'm using autocad com api as opposed to
managed .net api?

what would the equivalent line look like in managed .net api?

the examples i've seen and test apps i've started playing with previously
just referenced acmdg.dll and acdbmgd

in this one the refs are: acmgd, autoCad, and axdbLib

Is that an indication that com interop is being used?

In general if I look at a strange piece of code how do i know if it's com
interop versus .net api?

Thanks for any info

mark

[Anonymous]

yeah that kinda sucks but i've been copying to text file a lot of basics
from that site.
i have to find the read and write text objects stuff and the get user input
section...
thanks for reminding me of that site.
mark

"Tony Tanzillo" wrote in message
news:6293323@discussion.autodesk.com...
Visit the online documentation (I just can't believe they're playing that
game --- not making it available offline), and you'll find a lot of basic
examples that are oriented towards newcomers, including ones that show how
to get input using the managed API:

http://docs.autodesk.com/ACD/2010/ENU/AutoCAD%20.NET%20Developer's%20Guide/index.html


--
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");

"mp" wrote in message
news:6293229@discussion.autodesk.com...
I'm new to dotnet and am tasked to modify an existing program so have to do
some quick learning...

I can build and run the app but get the following warnins in the errorlist
window
"Path to dll .dll" does not contain any types that can be unregistered for
COM Interop.
"Path to dll .dll" does not contain any types that can be registered for COM
Interop.

there is a reference to acad type library in the project so i assume it's
using interop as I see lines like
m_acadDoc.Utility.GetString

does a line like that indicate i'm using autocad com api as opposed to
managed .net api?

what would the equivalent line look like in managed .net api?

the examples i've seen and test apps i've started playing with previously
just referenced acmdg.dll and acdbmgd

in this one the refs are: acmgd, autoCad, and axdbLib

Is that an indication that com interop is being used?

In general if I look at a strange piece of code how do i know if it's com
interop versus .net api?

Thanks for any info

mark

[Anonymous]

now i'm on that site looking for how to attach xdata, extension
dictionaries, and xrecords
if i search on xdata i only get an example of filtering a selection set for
xdata

if i search for xrecords i get one topic on layer states

if i search for extension dictionary i get 20 topics, none of which deal
with extension dicrtioaries
???
wtf?
:-)
mark


"mp" wrote in message
news:6293455@discussion.autodesk.com...
yeah that kinda sucks but i've been copying to text file a lot of basics
from that site.
i have to find the read and write text objects stuff and the get user input
section...
thanks for reminding me of that site.
mark

"Tony Tanzillo" wrote in message
news:6293323@discussion.autodesk.com...
Visit the online documentation (I just can't believe they're playing that
game --- not making it available offline), and you'll find a lot of basic
examples that are oriented towards newcomers, including ones that show how
to get input using the managed API:

http://docs.autodesk.com/ACD/2010/ENU/AutoCAD%20.NET%20Developer's%20Guide/index.html


--
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");

"mp" wrote in message
news:6293229@discussion.autodesk.com...
I'm new to dotnet and am tasked to modify an existing program so have to do
some quick learning...

I can build and run the app but get the following warnins in the errorlist
window
"Path to dll .dll" does not contain any types that can be unregistered for
COM Interop.
"Path to dll .dll" does not contain any types that can be registered for COM
Interop.

there is a reference to acad type library in the project so i assume it's
using interop as I see lines like
m_acadDoc.Utility.GetString

does a line like that indicate i'm using autocad com api as opposed to
managed .net api?

what would the equivalent line look like in managed .net api?

the examples i've seen and test apps i've started playing with previously
just referenced acmdg.dll and acdbmgd

in this one the refs are: acmgd, autoCad, and axdbLib

Is that an indication that com interop is being used?

In general if I look at a strange piece of code how do i know if it's com
interop versus .net api?

Thanks for any info

mark

[chiefbraincloud]

1) In VB.NET the 'Register for COM Interop' toggle is at the very bottom of the page in the Project Properties window, on the Compile Tab.

2) Tony's comment about the COM code using those referenced files is correct, but If you are just 'looking at strange code', one dead giveaway is that equivalent COM objects usually have 'Acad' as a prefix, where the managed objects do not. eg. AcadBlockReference in COM versus BlockReference in managed.

[Anonymous]

Thanks Chief!

wrote in message news:6293996@discussion.autodesk.com...
1) In VB.NET the 'Register for COM Interop' toggle is at the very bottom of
the page in the Project Properties window, on the Compile Tab.

2) Tony's comment about the COM code using those referenced files is
correct, but If you are just 'looking at strange code', one dead giveaway is
that equivalent COM objects usually have 'Acad' as a prefix, where the
managed objects do not. eg. AcadBlockReference in COM versus BlockReference
in managed.

[Anonymous]

Sorry, I have no clue about what's going on with that online documentation.

It's pretty horrible if you ask me.

--
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");

"mp" wrote in message
news:6293456@discussion.autodesk.com...
now i'm on that site looking for how to attach xdata, extension
dictionaries, and xrecords
if i search on xdata i only get an example of filtering a selection set for
xdata

if i search for xrecords i get one topic on layer states

if i search for extension dictionary i get 20 topics, none of which deal
with extension dicrtioaries
???
wtf?
:-)
mark


"mp" wrote in message
news:6293455@discussion.autodesk.com...
yeah that kinda sucks but i've been copying to text file a lot of basics
from that site.
i have to find the read and write text objects stuff and the get user input
section...
thanks for reminding me of that site.
mark

"Tony Tanzillo" wrote in message
news:6293323@discussion.autodesk.com...
Visit the online documentation (I just can't believe they're playing that
game --- not making it available offline), and you'll find a lot of basic
examples that are oriented towards newcomers, including ones that show how
to get input using the managed API:

http://docs.autodesk.com/ACD/2010/ENU/AutoCAD%20.NET%20Developer's%20Guide/index.html


--
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");

"mp" wrote in message
news:6293229@discussion.autodesk.com...
I'm new to dotnet and am tasked to modify an existing program so have to do
some quick learning...

I can build and run the app but get the following warnins in the errorlist
window
"Path to dll .dll" does not contain any types that can be unregistered for
COM Interop.
"Path to dll .dll" does not contain any types that can be registered for COM
Interop.

there is a reference to acad type library in the project so i assume it's
using interop as I see lines like
m_acadDoc.Utility.GetString

does a line like that indicate i'm using autocad com api as opposed to
managed .net api?

what would the equivalent line look like in managed .net api?

the examples i've seen and test apps i've started playing with previously
just referenced acmdg.dll and acdbmgd

in this one the refs are: acmgd, autoCad, and axdbLib

Is that an indication that com interop is being used?

In general if I look at a strange piece of code how do i know if it's com
interop versus .net api?

Thanks for any info

mark

[Anonymous]

{quote}

what would be an example of a com server

{quote}

AutoCAD is a COM server.

You can build COM servers that can be loaded into AutoCAD and be accessed
from another process, in the same way you access AutoCAD COM objects from
another process. That allows you to expose functionality that cannot be used
directly from another process, with the COM server acting as a 'middle-man',
or the 'in-process' component (in AutoCAD's process that is) in a
multi-component solution that might also include another standalone
executable, an Excel VBA script, etc.

In that scenario, an out-of-process component or standalone exeuctable can
talk to the in-process COM server (the 'middle-man') which can perform tasks
that can only be done from within AutoCAD's process, or can only be done
efficiently from there.

Moving to a managed C# solution will require you to become a bit more
familiar with the managed API in general, which is more complicated than the
COM API.

There are some parts of the managed API that have rough conterparts to the
COM API, but in most cases it is not that straightfoward and so translating
from a COM based app to a managed app will require some learning and
practicle hands-on experience with the managed API before you'll be able to
pull that off.

--
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");

"mp" wrote in message
news:6293424@discussion.autodesk.com...
Hi Tony,
Thanks for your response. what would be an example of a com server, in other
words, what kind of application would need to be a com server?
this app just creates some commands in acad that read and write some acad
objects and writes some xdata to some objects. So I could move that
functionality to c# managed api right? If I went that route, what would the
"get acad' lines look like, as opposed to the current:
m_AcadApp = TryCast(GetObject(, "AutoCAD.Application"), AcadApplication)

I'm guessing it's something like the following:

C#

using Autodesk.AutoCAD.Runtime;
using Autodesk.AutoCAD.ApplicationServices;
using Autodesk.AutoCAD.DatabaseServices;
...

m_AcadApp = Application

so "application" automatically becomes the acad app in the using scope?
right?



Thanks

mark




"Tony Tanzillo" wrote in message
news:6293324@discussion.autodesk.com...
As to your specific question, the warning means your project settings are
set to register your assembly or executable for COM. You only do that if you
are building a COM server, not a client (which is what you have). I'm not
familiar with where it is in VB.NET, but somewhere in your project's
properties, you'll find a setting that controls this. \

If a project uses AutoCAD COM APIs, it will reference AutoCAD and AxDbLib.

right, those two are refed, so if i change to net api i can lose those and
just ref in acmgd and axdbmgd right?
then what
The assemblies whose names contain 'mgd' are managed assemblies.

--
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");

"mp" wrote in message
news:6293229@discussion.autodesk.com...
I'm new to dotnet and am tasked to modify an existing program so have to do
some quick learning...

snip

m_acadDoc.Utility.GetString

does a line like that indicate i'm using autocad com api as opposed to
managed .net api?

what would the equivalent line look like in managed .net api?

the examples i've seen and test apps i've started playing with previously
just referenced acmdg.dll and acdbmgd

in this one the refs are: acmgd, autoCad, and axdbLib

Is that an indication that com interop is being used?

In general if I look at a strange piece of code how do i know if it's com
interop versus .net api?

Thanks for any info

mark

[Anonymous]

So if i understand you correctly, ...
in a scenario of an active x dll created in vb6, injected into acad's
process space with a Getinterface call from a standalone exe also created in
vb6..
the dll is a com server and the exe is a com client?
is that correct?

on the subject of moving to managed net api as compared to activex(vb6)
are there benefits over and above the fact that acad is following ms lead of
"abandoning" vb6/activex technology
in particular it seemed an ax dll and exe were somewhat harder to reverse
engineer (for a casual cad user/amature programmer type) than a dotnet app?
It doesn't seem to be much concern about that issue in general in the dotnet
community, is that right?
not that anything i write is worth protecting, just curious if serious
progers who invest considerable business intelligence into their objects
have any concerns with the transparency of the dotnet technology?

"Tony Tanzillo" wrote in message
news:6294056@discussion.autodesk.com...
{quote}

what would be an example of a com server

{quote}

AutoCAD is a COM server.

You can build COM servers that can be loaded into AutoCAD and be accessed
from another process, in the same way you access AutoCAD COM objects from
another process. That allows you to expose functionality that cannot be used
directly from another process, with the COM server acting as a 'middle-man',
or the 'in-process' component (in AutoCAD's process that is) in a
multi-component solution that might also include another standalone
executable, an Excel VBA script, etc.

In that scenario, an out-of-process component or standalone exeuctable can
talk to the in-process COM server (the 'middle-man') which can perform tasks
that can only be done from within AutoCAD's process, or can only be done
efficiently from there.

Moving to a managed C# solution will require you to become a bit more
familiar with the managed API in general, which is more complicated than the
COM API.

There are some parts of the managed API that have rough conterparts to the
COM API, but in most cases it is not that straightfoward and so translating
from a COM based app to a managed app will require some learning and
practicle hands-on experience with the managed API before you'll be able to
pull that off.

--
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");

"mp" wrote in message
news:6293424@discussion.autodesk.com...
Hi Tony,
Thanks for your response. what would be an example of a com server, in other
words, what kind of application would need to be a com server?
this app just creates some commands in acad that read and write some acad
objects and writes some xdata to some objects. So I could move that
functionality to c# managed api right? If I went that route, what would the
"get acad' lines look like, as opposed to the current:
m_AcadApp = TryCast(GetObject(, "AutoCAD.Application"), AcadApplication)

I'm guessing it's something like the following:

C#

using Autodesk.AutoCAD.Runtime;
using Autodesk.AutoCAD.ApplicationServices;
using Autodesk.AutoCAD.DatabaseServices;
...

m_AcadApp = Application

so "application" automatically becomes the acad app in the using scope?
right?



Thanks

mark




"Tony Tanzillo" wrote in message
news:6293324@discussion.autodesk.com...
As to your specific question, the warning means your project settings are
set to register your assembly or executable for COM. You only do that if you
are building a COM server, not a client (which is what you have). I'm not
familiar with where it is in VB.NET, but somewhere in your project's
properties, you'll find a setting that controls this. \

If a project uses AutoCAD COM APIs, it will reference AutoCAD and AxDbLib.

right, those two are refed, so if i change to net api i can lose those and
just ref in acmgd and axdbmgd right?
then what
The assemblies whose names contain 'mgd' are managed assemblies.

--
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");

"mp" wrote in message
news:6293229@discussion.autodesk.com...
I'm new to dotnet and am tasked to modify an existing program so have to do
some quick learning...

snip

m_acadDoc.Utility.GetString

does a line like that indicate i'm using autocad com api as opposed to
managed .net api?

what would the equivalent line look like in managed .net api?

the examples i've seen and test apps i've started playing with previously
just referenced acmdg.dll and acdbmgd

in this one the refs are: acmgd, autoCad, and axdbLib

Is that an indication that com interop is being used?

In general if I look at a strange piece of code how do i know if it's com
interop versus .net api?

Thanks for any info

mark

[Anonymous]

{quote}

in a scenario of an active x dll created in vb6, injected into acad's
process space with a Getinterface call from a standalone exe also created in
vb6.. the dll is a com server and the exe is a com client?
is that correct?

{quote}

Right.

There are plenty of benefits to the managed API, mainly because it is far
more extensive, robust and powerful than the ActiveX API. Many of the common
problems confronted by VBA programmers are not problems at all with the
managed API.

Of course, along with that power comes greater complexity and a far steeper
learning curve.

As far as protecting your IP, it certainly is a concern for those who have
significant invesments in it, but for most in-house development of AutoCAD
based solutions, I don't think it is a major issue.

--
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");

"mp" wrote in message
news:6294461@discussion.autodesk.com...
So if i understand you correctly, ...
in a scenario of an active x dll created in vb6, injected into acad's
process space with a Getinterface call from a standalone exe also created in
vb6..
the dll is a com server and the exe is a com client?
is that correct?

on the subject of moving to managed net api as compared to activex(vb6)
are there benefits over and above the fact that acad is following ms lead of
"abandoning" vb6/activex technology
in particular it seemed an ax dll and exe were somewhat harder to reverse
engineer (for a casual cad user/amature programmer type) than a dotnet app?
It doesn't seem to be much concern about that issue in general in the dotnet
community, is that right?
not that anything i write is worth protecting, just curious if serious
progers who invest considerable business intelligence into their objects
have any concerns with the transparency of the dotnet technology?

"Tony Tanzillo" wrote in message
news:6294056@discussion.autodesk.com...
{quote}

what would be an example of a com server

{quote}

AutoCAD is a COM server.

You can build COM servers that can be loaded into AutoCAD and be accessed
from another process, in the same way you access AutoCAD COM objects from
another process. That allows you to expose functionality that cannot be used
directly from another process, with the COM server acting as a 'middle-man',
or the 'in-process' component (in AutoCAD's process that is) in a
multi-component solution that might also include another standalone
executable, an Excel VBA script, etc.

In that scenario, an out-of-process component or standalone exeuctable can
talk to the in-process COM server (the 'middle-man') which can perform tasks
that can only be done from within AutoCAD's process, or can only be done
efficiently from there.

Moving to a managed C# solution will require you to become a bit more
familiar with the managed API in general, which is more complicated than the
COM API.

There are some parts of the managed API that have rough conterparts to the
COM API, but in most cases it is not that straightfoward and so translating
from a COM based app to a managed app will require some learning and
practicle hands-on experience with the managed API before you'll be able to
pull that off.

--
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");

"mp" wrote in message
news:6293424@discussion.autodesk.com...
Hi Tony,
Thanks for your response. what would be an example of a com server, in other
words, what kind of application would need to be a com server?
this app just creates some commands in acad that read and write some acad
objects and writes some xdata to some objects. So I could move that
functionality to c# managed api right? If I went that route, what would the
"get acad' lines look like, as opposed to the current:
m_AcadApp = TryCast(GetObject(, "AutoCAD.Application"), AcadApplication)

I'm guessing it's something like the following:

C#

using Autodesk.AutoCAD.Runtime;
using Autodesk.AutoCAD.ApplicationServices;
using Autodesk.AutoCAD.DatabaseServices;
...

m_AcadApp = Application

so "application" automatically becomes the acad app in the using scope?
right?



Thanks

mark




"Tony Tanzillo" wrote in message
news:6293324@discussion.autodesk.com...
As to your specific question, the warning means your project settings are
set to register your assembly or executable for COM. You only do that if you
are building a COM server, not a client (which is what you have). I'm not
familiar with where it is in VB.NET, but somewhere in your project's
properties, you'll find a setting that controls this. \

If a project uses AutoCAD COM APIs, it will reference AutoCAD and AxDbLib.

right, those two are refed, so if i change to net api i can lose those and
just ref in acmgd and axdbmgd right?
then what
The assemblies whose names contain 'mgd' are managed assemblies.

--
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");

"mp" wrote in message
news:6293229@discussion.autodesk.com...
I'm new to dotnet and am tasked to modify an existing program so have to do
some quick learning...

snip

m_acadDoc.Utility.GetString

does a line like that indicate i'm using autocad com api as opposed to
managed .net api?

what would the equivalent line look like in managed .net api?

the examples i've seen and test apps i've started playing with previously
just referenced acmdg.dll and acdbmgd

in this one the refs are: acmgd, autoCad, and axdbLib

Is that an indication that com interop is being used?

In general if I look at a strange piece of code how do i know if it's com
interop versus .net api?

Thanks for any info

mark

[Anonymous]

{quote}

but for most in-house development of AutoCAD
based solutions, I don't think it is a major issue.
{quote}
that's understandable but at the professional level does one see more
discussion of that topic, or resistance to adopting that kind of technology
for the long run., or discussion of alternates to using dotnet based
solutions? i obviously don't know what i'm talking about 🙂 but my
understanding is that one can look at any net dll and "read" it via
reflector or ?... so i'd assume acad isn't written in dotnet or windows os
or office products etc...
or is acad written in dotnet now? obviously it's tied to the framework in
some ways and displays the resultant slowness that seems to come with that
technology...like the painfully slow ribbon abomination...
?

"Tony Tanzillo" wrote in message
news:6294863@discussion.autodesk.com...
{quote}

in a scenario of an active x dll created in vb6, injected into acad's
process space with a Getinterface call from a standalone exe also created in
vb6.. the dll is a com server and the exe is a com client?
is that correct?

{quote}

Right.

There are plenty of benefits to the managed API, mainly because it is far
more extensive, robust and powerful than the ActiveX API. Many of the common
problems confronted by VBA programmers are not problems at all with the
managed API.

Of course, along with that power comes greater complexity and a far steeper
learning curve.

As far as protecting your IP, it certainly is a concern for those who have
significant invesments in it, but for most in-house development of AutoCAD
based solutions, I don't think it is a major issue.

--
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");

"mp" wrote in message
news:6294461@discussion.autodesk.com...
So if i understand you correctly, ...
in a scenario of an active x dll created in vb6, injected into acad's
process space with a Getinterface call from a standalone exe also created in
vb6..
the dll is a com server and the exe is a com client?
is that correct?

on the subject of moving to managed net api as compared to activex(vb6)
are there benefits over and above the fact that acad is following ms lead of
"abandoning" vb6/activex technology
in particular it seemed an ax dll and exe were somewhat harder to reverse
engineer (for a casual cad user/amature programmer type) than a dotnet app?
It doesn't seem to be much concern about that issue in general in the dotnet
community, is that right?
not that anything i write is worth protecting, just curious if serious
progers who invest considerable business intelligence into their objects
have any concerns with the transparency of the dotnet technology?

"Tony Tanzillo" wrote in message
news:6294056@discussion.autodesk.com...
{quote}

what would be an example of a com server

{quote}

AutoCAD is a COM server.

You can build COM servers that can be loaded into AutoCAD and be accessed
from another process, in the same way you access AutoCAD COM objects from
another process. That allows you to expose functionality that cannot be used
directly from another process, with the COM server acting as a 'middle-man',
or the 'in-process' component (in AutoCAD's process that is) in a
multi-component solution that might also include another standalone
executable, an Excel VBA script, etc.

In that scenario, an out-of-process component or standalone exeuctable can
talk to the in-process COM server (the 'middle-man') which can perform tasks
that can only be done from within AutoCAD's process, or can only be done
efficiently from there.

Moving to a managed C# solution will require you to become a bit more
familiar with the managed API in general, which is more complicated than the
COM API.

There are some parts of the managed API that have rough conterparts to the
COM API, but in most cases it is not that straightfoward and so translating
from a COM based app to a managed app will require some learning and
practicle hands-on experience with the managed API before you'll be able to
pull that off.

--
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");

"mp" wrote in message
news:6293424@discussion.autodesk.com...
Hi Tony,
Thanks for your response. what would be an example of a com server, in other
words, what kind of application would need to be a com server?
this app just creates some commands in acad that read and write some acad
objects and writes some xdata to some objects. So I could move that
functionality to c# managed api right? If I went that route, what would the
"get acad' lines look like, as opposed to the current:
m_AcadApp = TryCast(GetObject(, "AutoCAD.Application"), AcadApplication)

I'm guessing it's something like the following:

C#

using Autodesk.AutoCAD.Runtime;
using Autodesk.AutoCAD.ApplicationServices;
using Autodesk.AutoCAD.DatabaseServices;
...

m_AcadApp = Application

so "application" automatically becomes the acad app in the using scope?
right?



Thanks

mark




"Tony Tanzillo" wrote in message
news:6293324@discussion.autodesk.com...
As to your specific question, the warning means your project settings are
set to register your assembly or executable for COM. You only do that if you
are building a COM server, not a client (which is what you have). I'm not
familiar with where it is in VB.NET, but somewhere in your project's
properties, you'll find a setting that controls this. \

If a project uses AutoCAD COM APIs, it will reference AutoCAD and AxDbLib.

right, those two are refed, so if i change to net api i can lose those and
just ref in acmgd and axdbmgd right?
then what
The assemblies whose names contain 'mgd' are managed assemblies.

--
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");

"mp" wrote in message
news:6293229@discussion.autodesk.com...
I'm new to dotnet and am tasked to modify an existing program so have to do
some quick learning...

snip

m_acadDoc.Utility.GetString

does a line like that indicate i'm using autocad com api as opposed to
managed .net api?

what would the equivalent line look like in managed .net api?

the examples i've seen and test apps i've started playing with previously
just referenced acmdg.dll and acdbmgd

in this one the refs are: acmgd, autoCad, and axdbLib

Is that an indication that com interop is being used?

In general if I look at a strange piece of code how do i know if it's com
interop versus .net api?

Thanks for any info

mark

[Anonymous]

I don't see that...i'm on express...maybe it's only avail in full studio?
only thing on bottom of compile tab is advanced compile options button
likewise nothing on the dialog that pulls up has register for com interop
either

wrote in message news:6293996@discussion.autodesk.com...
1) In VB.NET the 'Register for COM Interop' toggle is at the very bottom of
the page in the Project Properties window, on the Compile Tab.

[chiefbraincloud]

Could be an express thing. I'm not sure. I'm on VS 2005 Professional and the attached image is what my compile page looks like.