Topic: VS2010, C3D2013, x86/x64, COM, .NET madness

[Jeff_M]

I think this release is the one that has officially driven me insane. I'm not sure how to best describe my frustration in the hopes of finding a solution, so I'll start at the beginning. If I bore you, or put you to sleep, I apologize now. Working on a fairly large VS2010 Solution, comprised of 5 separate projects all linked to together. These all work perfectly well in C3D2010-C3D2012 in both x64 & x86 flavors (one dll per Acad version), some using strictly .NET managed code, others have COM mixed in. Enter C3D2013 and notice that MOST of the old COM Interops has been ported to .NET wrappers. So we decide to update our code base to utilize the new offerings. First thing to do, make a full copy of the solution and change all of the references. With a few minor tweaks to satisfy the new Acad2013 Core split, it builds and runs. I then spend the next few weeks going through and changing all the code previously using COM to it's .NET counterpart, going in steps (change/build/debug) so as to ease the debug process. There are a few lingering issues, but most everything appears to have been ported nicely.

In the meantime, it's decided to create a 2013 version using the old COM based code. This builds and runs perfectly on my Win7x64 machine. I decide to test on a XPx86 as a precaution. Good thing! It doesn't work, failing at every attempt to access a C3D COM object. After asking many questions, and getting many varied answers, it was finally determined that separate builds must be made for x64 & x86, using the Interops from the installs of each of those 2 flavors. I found a way to do so (again after exhaustive searches and some trial & error) in the same VS Solution, and this route has worked well for the old project.

Since I now knew I needed these separate builds, I went ahead and made the same changes to the new .NET solution and projects. Test the builds, and all is smooth in both x86 & x64 installs. Great, now I can get back to those problem areas that didn't port quite right. Looks like I need to make a change to a form with user controls created in one of the other projects (MANY of the forms we have use this same process), so I click the form to open it, and am presented with an error screen, saying it can't load the form in the designer due to a missing file (AeccDbMgd.dll). The missing file is one that IS referenced, and the project would not build at all if it was unable to be found. So I know VS can find the file, but for some unknown reason the Designer is not finding it. And further inspection of the forms & controls is not giving any clues as to why, since none of them rely on the 'missing' file to construct the forms. I've spent literally days working on this now, and have found ONE web page that pretty much describes the issue I'm seeing (this one) but after following the suggestions there, I am still stuck with projects  that cannot use the controls previously created. Even trying to use it in a form in the same project throws this error. (By 'cannot use', I mean create a new form or edit an existing one in the Designer. The solution still builds and runs.)

All this, because MS & Autodesk decided to make things 'simpler' by removing the Interops from the GAC and Embedding them into the projects, thereby forcing the separate builds. So far, I'm at a loss on how to attempt correcting this. If you made it this far without snoring, thanks! If you have any suggestions, double thanks!

Jeff

[huiz]

You are not using AutoCAD Dialogs (instead of WinForms) which you call via a button or code?

Maybe that is changed in 2013 dbmgd.dll.

[TheMaster]

The SDK comes with special versions of the managed assemblies for vanilla AutoCAD (AcDbMgd.dll, AcMgdDll, etc.).  The reason for those special versions is because the production versions of the assemblies cannot be loaded into Visual Studio (which happens when you have designable objects like forms and controls, whose code files reference types from the AutoCAD assemblies).

If there is no equivalent modified version of AeccDbMgd.dll, then referencing types from that assembly in designable controls or forms will probably cause the failure you describe.

[poncelet]

I think this release is the one that has officially driven me insane.

Jeff i think they need a drone attack. For real.

[Jeff_M]

Thanks, Tony. That makes perfect sense, and no, they don't provide modified versions. What I did find, after reading your post, was that by going back and adding back in the AnyCPU option for all projects that the Designer appears to work again (at least in the small test Solution I have setup for this). So this means I now need to maintain 3 build platforms. 1 for editing/debugging and 1 each for the x86/x64 release builds. <sigh> Sure glad they made this simpler. And I really hope this works for the bigger real world project. I will find out this evening...

[BlackBox]

... Ironic that you'd need to maintain each an x86, and x64 build when you've set for 'any cpu', no?   

I'm sure there's more to this than I am able to understand; just saying.

[Jeff_M]

RenderMan, you would think it would be that simple. And it kind of is, while at the same time not.
http://adndevblog.typepad.com/infrastructure/2012/04/com-references-on-civil-3d-2013.html

There were a couple ways I could address this (at least what I discovered, there may be others):
1 solution with 5 projects, with build options for x86 & x64 which auto-switch references by changing the build platform OR
2 solutions with 5 projects each, each of which pointed to the respective 32/64 bit interop.dll's, with 1 build platform for AnyCPU

I chose the first option, which was working fine (and does work fine for the mostly COM version which is another separate solution). I only discovered a problem when I went to edit a form which has references to that one dll (AeccDbMgd), which previously had referenced the COM Interops instead.

[Jeff_M]

Well, another exercise in futility. Why my small test project works ok using AnyCPU, but the 'real' project does not, is beyond my level of comprehension I guess. Time to start adding things until it stops working. Although from what it sounds like from TheMaster's post, the test project is the one that isn't operating as expected. But if I can at least get the test project to stop working in Designer mode, I could submit it to ADN to see what they have to say about this, uh, messy situation.

[BlackBox]

Jeff, thanks for the link and clarification, as always. It will come in handy if/when we get 2013; as it happens we're still waiting for a full 2011 implementation. 

I hope you are able to resolve the version issue soon. Good luck!

[TheMaster]

Well, another exercise in futility. Why my small test project works ok using AnyCPU, but the 'real' project does not, is beyond my level of comprehension I guess. Time to start adding things until it stops working. Although from what it sounds like from TheMaster's post, the test project is the one that isn't operating as expected. But if I can at least get the test project to stop working in Designer mode, I could submit it to ADN to see what they have to say about this, uh, messy situation.

Look at the control or form that causes the failure when you try to open it in the designer.

If there are properties whose types are in the C3D assembly, or there is
code that's called from the constructor of the control that uses types from
the C3D assembly, that's most-likely the culprit.

You can in some cases refactor your code to prevent it.

[Jeff_M]

Thanks once again, Tony. I checked my test solution and I had added a method to the usercontrol to return the first Alignment in a drawing. I could add the usercontrol to a form without issue. I then changed that method to a property and bam, the form with the usercontrol added would no longer load, nor could I add the control to any other form. So it looks like refactoring the properties to methods should do the trick.

I shall report back after I test this on a few of the problem controls.

[TheMaster]

So it looks like refactoring the properties to methods should do the trick.

The problem with properties that have AutoCAD types,
is that the designer will try to serialize them unless you
tell it not to, and it will try to display their values in the
Property grid in the IDE. Doing either of those is what
triggers the loading of the property type from the AutoCAD
assembly.

To prevent the IDE from doing either, you can apply these
attributes to public properties that have AutoCAD types:

Code: [Select]


[DesignerSerializationVisibility( DesignerSerializationVisibility.Hidden )]
[Browsable( false )]
[EditorBrowsable( EditorBrowsableState.Never )]


These attributes prevent the designer from showing a property and
its value in the IDE, and from generating code to serialize/deserialize
the property to the xxx.designer.cs file.

[Jeff_M]

Thanks for the explanation! I'm starting to grasp what is going on now. Unfortunately this doesn't seem to be helping, Tony. Providing this is how it is supposed to implemented:

Code - C#: [Select]

1.         [DesignerSerializationVisibility(DesignerSerializationVisibility.Hidden)]
2.         [Browsable(false)]
3.         [EditorBrowsable(EditorBrowsableState.Never)]
4.         public Alignment FirstAlignment
5.         {
6.             get
7.             {
8.                 Alignment align = null;
9.                 using (Transaction tr = HostApplicationServices.WorkingDatabase.TransactionManager.StartTransaction())
10.                 {
11.                     align = (Alignment)CivilApplication.ActiveDocument.GetAlignmentIds()[0].GetObject(OpenMode.ForRead);
12.                     tr.Commit();
13.                 }
14.                 return align;
15.             }
16.         }
17.  

[TheMaster]

Thanks for the explanation! I'm starting to grasp what is going on now. Unfortunately this doesn't seem to be helping, Tony. Providing this is how it is supposed to implemented:

Code - C#: [Select]

1.         [DesignerSerializationVisibility(DesignerSerializationVisibility.Hidden)]
2.         [Browsable(false)]
3.         [EditorBrowsable(EditorBrowsableState.Never)]
4.         public Alignment FirstAlignment
5.         {
6.             get
7.             {
8.                 Alignment align = null;
9.                 using (Transaction tr = HostApplicationServices.WorkingDatabase.TransactionManager.StartTransaction())
10.                 {
11.                     align = (Alignment)CivilApplication.ActiveDocument.GetAlignmentIds()[0].GetObject(OpenMode.ForRead);
12.                     tr.Commit();
13.                 }
14.                 return align;
15.             }
16.         }
17.  

Changing the property to a method might be the only way to solve it.

[Jeff_M]

Well, great news! Refactoring the Properties to Methods has solved the Designer issue. It didn't take all that long to go through and fix the controls, and the code accessing those properties. In fact, it took FAR less time than what I spent trying to find a resolution to this via Google. Many, many, thanks for showing me the cause, and leading me to the solution, Tony. You've definitely earned your moniker, imho.