Reply

64bit AddIn

[ Edited ]

 

I have started working on an Addin in .NET, since my current AddIn is made in VB6 and thus only works for the 32bit version of Solid Edge. Since we are going to move on to 64 bit Solid Edge quite soon, I will have to remake my addin (which is approaching 15000 lines ) to .Net so it works with both 32 and 64bit SE.

I have made a very simple addin so far, which only add buttons, nothing more yet. It also has the ComRegisterFunction / UnregisterFunction added, which should add the registerkeys.

But the problem lies in trying to compile / debug the addin for SE x64. I have disabled the "Register for COM interop" so it doesn't use the 32bit Regasm tool, and I have added a custom post-build line to use the 64bit RegASM tool.

But everytime I try to use the 64bit RegASM tool, it says it is not a "Valid .NET Assembly". The 32bit tool works just fine. But then it doesn't get loaded into Solid Edge. I have spend hours searching the internet, but I couldn't find a thing to get rid of this error.

I hope someone here knows how to fix this, as I have no more ideas on how to fix it.

 

Posted by: T. Jissink
Post date: 6/10/2010 10:28:09 PM

5 REPLIES

RE: 64bit AddIn

[ Edited ]

 

Got it to work: I was using the .NET framework 2.0 regasm.exe tool, while my project was using .NET framework 4.0

Changed it so it uses the 4.0 regasm tool, now it works great

 

Posted by: T. Jissink
Post date: 6/11/2010 9:55:27 AM

RE: 64bit AddIn

[ Edited ]

Hi Tymen,

 

just some info: I have been developing a .Net 4.0 add-in and was having problems with SE crashing when closing. It turned out that this only happened when accessing files managed with Insight. The problem is a dll called WebClientConsumer.dll and I haven't found a way to fix it (I don't think there will be a way without access to the internal workings of WebClientConsumer.dll). In the meantime I have dropped back to .Net 3.5 and everything seems to be fine.

 

Interestingly, SE still crashes when debugging with VS2010 - I think this automatically loads version 4 of the .Net framework.

 

Just thought I'd share the info - I don't thinkk there are too many of us using .Net 4.0 at the moment...

 

Cheers

Calum

 

Posted by: Calum McLellan
Post date: 6/12/2010 3:41:08 AM

RE: 64bit AddIn

[ Edited ]

 

Thanks for your reply Callum. We don't use Insight here so we won't be having the trouble you had.

An interesting thing is, which I didn't know, is that you can't add/remove code while debugging in 64 bit. As I am often coding quite alot while debugging, this is getting quite annoying.

Buidling the addin for 32bit, and compile it with "Any CPU" will make it work on 64bit later on right? This way I could add/remove code while debugging.

 

Posted by: T. Jissink
Post date: 6/15/2010 7:25:22 PM

RE: 64bit AddIn

[ Edited ]

'I have disabled the "Register for COM interop" so it doesn't use the 32bit Regasm tool, and I have added a custom post-build line to use the 64bit RegASM tool.'

 

Tymen, could you ellaborate on this please? I assume you mean that you have unchecked the 'Make assembly COM-Visible' in Assembly Information and have added a post build event to ensure your add-in works on 64bit SE. What is the syntax for the build event?

 

I have a .NET Framework 3.5 add-in, developned in VB.NET (VS2008) that works fine in 32bit SE, but I cannot get it working in 64bit. I'd really appreciate some help with this.

 

Regards,

Dave

 

Posted by: Dave Rothan
Post date: 8/3/2010 2:53:53 AM

RE: 64bit AddIn

[ Edited ]

 

SysRg,

Solid Edge has a VB.NET addin sample (under sdk\samples\addins\vb.net. There are some bat files that build x86, x64 and anycpu versions of the add-in. The readme.txt is full of naseating details of the problems you may encounter like the regasm issue. It also explains how to capture the command line from the VS output window so one can create/modify the bat file approach to building. The addin uses the bat file approach in order to embed native win32 resources into the add-in DLL. I believe the add-in also shows how to build a separate resource DLL (with win32 resources) so the resources and code can be decoupled (allows one to modify code for a service pack fix without having to worry about internationalization of resources).

 

Posted by: R.D. Holland
Post date: 9/24/2010 5:05:03 AM