32-bit C# .NET plugin for 64-bit AutoCAD

[Anonymous]

Hello

I'm trying to build a plug-in for 64-bit AutoCAD 2013, using Visual Studio 2010. Target = x64 works. When I choose a target = x86, everything is fine in MS VS. But after I load the .dll to AutoCAD, there is no my command. Is it possible to use x32 MS VS debugger , that can make changes on fly? I need it very much.

I tried to install a 32-bit version of AutoCAD on my x64 Windows 7, but I can not.

Thanks in advance.

[_gile]

Hi,

If your plug-in only uses managed .NET (neither using COM nor P/Invoking unmanaged code) and is compiled targeting 'any CPU', it will work on both 32 and 64 bits.

If you're using COM (or unmanaged methods) which are platform dependant you'd have to compile two projects: one for 32 bits and another for 64 bits.

[Anonymous]

My plug-in only uses Managed .NET code.

When I use target = any CPU, the x64 code is executed.

Can I use a x32 code on my computer for debudding?

How is it setuped in Autocad? Autocad does not see my x32 plug-in. There is no my commands.

[_gile]

Why do you have a "x64 code" and a "x32 code" ? The code should be the same...

[Anonymous]

Code is the same.

I have other problem "How can I load x32 plugin .dll to 64-bit Autocad and

is it possible to debug the plugin .dll loaded into 64-bit AutoCAD with 32-bit debugger of MS VS 2010?"

[Anonymous]

People, how do you debug your plug-ins for Autocad?

Or all af you using MS VS 2012?

I asked the question of this topic, because in MS VS 2012 the flag was appered "prefer a x32 code generation". So if you use multiple target, at run-time the x32 machine code is generated. Post about it was published in blog "Through the interfase", where author writes ACAD plug-in. Thats lead me to idea, that it is possible to use x32 debugger even if you have 64-bit AutoCAD.

Thats why I asking, do any of experts know how to make the same thing in MS VS 2010?

Sorry for my English, It is not my native. If I write obscure text, please, ask me - I'll try to rewrite my ideas by other words.

I need the solution very much. It can make my work easier and faster.

Thank you in advance.

[OysteinW]

You can't debug in 32 bit mode running inside 64 bit AutoCAD, you should compile the dll as AnyCPU.

If Edit and Continue is the goal here, use a 32 bit computer running AutoCAD 32 bit. 

Or you can try using Visual Studio 2013 which supports Edit and Continue in 64 bit mode. 

-But I've encountered some problems with debugging AutoCAD in .NET mode using Visual Studio 2013: Drawing text doesn't display at all, and I'm getting a lot of "undefined shape #"-messages in the command line while regenerating the drawing. In addition, the STYLE command is highly unstable. 

The Edit and Continue feature worked nicely in VS2013, so I'm hoping the text-issue can be resolved somehow.

[Anonymous]

Thank you, but these news are very bad.

I afraid my computer can not support the latest versions of Autocad.

Now I'm very interested in:

Do anybody know what exactly AutoCAD uses in 32 bit version, that cannot allow it to be used in 64 bit Windows?

Because other applications the other way round (for example, MS Office) are recommend to install a 32 bit version on even 64 bit OS for compatibility with other programs on computer.

Today I read many similar questions of ACAD users, which were very sad in this state of affairs.

They have more problems then I, because they install acad on their computers and extensions, that their used for thir work earlier are not supported today, because extensions are only for x32 version.

Thank you for immediate answer.

[dgorsman]

I can debug, using VS Express 2010 on x64 AutoCAD.  I can't edit-and-continue, but I work around it.  I consider it a nice-to-have, not a complete full-stop deal breaker.

The reason why there is a "recommendation" for x32 MS Office is many user customizations make use of 32-bit controls which have no 64-bit equivalent.  Some AutoCAD users are in the same boat, where a third-party application they depend on is equally reliant on something, like a 32-bit control or JET database access, and the developer hasn't updated their code.  For the most part though its just a matter of moving the code forward - WCF or new form design instead of old 32-bit controls, ACE or System.Data instead of JET, and so on.

[Anonymous]

dgorsman,

I agree to you fully.

Autodest thinks that it is MS VS problem )))

But I'm still interested in question:

Why AutoCAD reject using virtualization (SysWow64) in Windows?

I've never heard something like this in other applicantions before.