Who? Me?…PDMWorks Enterprise API Development Gotchas With .NET
June 18, 2008
A year or two ago I read a book that changed the game for me. The book was called .NET Gotchas and it made me about 10x more effective as a developer. The book details 75 common pitfalls with .NET development and explains how to avoid them. I was knee-deep in a few of those pitfalls when I found the book at my local library. In fact, I was at the library specifically to get help for a few problems I was having with a PDMWE Addin project that I was working on at the time. The addin was written for .NET and even though the book was written based on an earlier version of the .NET Framework, it still did wonders for me and for my project.
Time went on and eventually I found myself at a PDMWorks Enterprise Addin development breakout session at SolidWorks World 2008 in San Diego. Although the presenter did a pretty good job explaining the process for creating, editing and debugging an Addin for PDMWE, he told attendees to select the “Register for COM Interop” button in Visual Studio to register their Addin for Interop. I knew at the time that this was a violation of Gotcha #73 – Simply turning the switch for COM Interop is dangerous. I kept my mouth shut at the time but I made a note to self to write up a PDMWorks Enterprise-specific Gotcha column based on some of the things that have tripped me up during my three years of Conisio / PDMWorks Enterprise API development.
Here are my top five:
#1 –PDMWorks Enterprise doesn’t like COM Interop assemblies that don’t include “interop” in the filename.
When referencing COM libraries from managed code using Visual Studio’s Project, Add Reference method, Visual Studio automatically creates the COM Interop assemblies for you and by default adds .interop to the filename just before .dll. However, sometimes it is necessary to create your own COM interop assemblies (to support multiple versions of an app for instance). In this situation, the developer specifies the filename arbitrarily (e.g. mySolidWorks2007assembly.dll, mySolidWorks2008assembly.dll, etc…). Additionally, you may be using interop assemblies provided by the software OEM (side note – it is usually a good idea to use these if they are available) in which case the assemblies’ filenames might also not include interop. So, there are a few scenarios in which you may run into a situation where you have a COM interop assembly that doesn’t have .interop in the filename. This is normally not a problem but for some reason PDMWorks Enterprise (this was last tested on 2007 but I suspect the issue is present in 2008 as well) does not recognize the interop assembly as an interop assembly unless it has interop in the name. In this situation, PDMWorks Enterprise will fail to bring the assembly down to the client machine to load with your addin. This in turn causes various loading and binding issues and an Addin that doesn’t work.
Solution:
Use the Type Library Importer tool to create an interop assembly with the name you desire from a COM assembly. For example, typing
tlbimp.exe MyActiveX.dll /out:Interop.MyActiveX.dll
at the Visual Studio command prompt will generate a COM Interop assembly named Interop.MyActiveX.dll from a COM assembly called MyActiveX.dll. If you need a strong-named interop assembly (also usually a good idea), then you should instead type
tlbimp.exe MyActiveX.dll /out:Interop.MyActiveX.dll/keyfile:MyKeyFile.snk
where MyKeyFile.snk is your company’s strong-name key.
#2 – Weakly named assemblies can cause security issues on Windows clients at run-time.
Microsoft introduced a number of security enhancements in .NET 2.0 that are meant to protect you from bad guys and boogie-men. These enhancements are specifically dealing with “trusted zones” and are generally helpful. However, if your assemblies were written in Visual Studio 2005 or later or were written in Visual Studio 2003 but don’t specify a pre-2.0 .NET framework in their .config file, then these enhancements will wreak havoc and mayhem on your addin.
Solution:
Unless you want to configure your assemblies as “trusted” on every machine, which by the way requires the .NET Framework Administration tool, then your best bet is to simply provide a strong-name to your assemblies. Note: Creating your assemblies in Visual Studio 2003 isn’t a good option due to the great enhancements in Visual Studio 2005 and Visual Studio 2008.
#3 – Using COM interop assemblies in your addin causes assembly loading issues if the COM assembly isn’t installed on the client machine beforehand.
COM Interop assemblies are really just wrappers for your COM assemblies. The COM assemblies still do most of the work. The wrapper just tells Windows to load the COM assembly using MSCOREE to marshal calls between your managed and unmanaged code. This means that the COM assembly must still be present on the machine running your addin. PDMWorks Enterprise will auto-magically download your COM Interop assembly (if it has interop in the filename) but this is not the case for the COM assembly itself. This is problematic in cases where you have so many clients using PDMWorks Enterprise that installing the COM assembly manually isn’t a good option. This issue usually presents itself via nasty assembly binding errors and will kill your Addin and anything else within a 50 meter kill-zone.
Solution:
Place a copy of the COM assembly in your PDMWorks Enterprise vault and write a PDMWorks Enterprise Addin to automatically install it in the Global Assembly Cache, GAC, on the PDMWorks Client. Once the COM assembly is deployed to the GAC on all clients, you should be able to run your addin with confidence. I haven’t tried doing this from the same Addin that requires the COM assembly but in theory it should be possible. You may have to explicitly load the assemblies in question using the System.Runtime.InteropServices and System.Reflection namespaces but I think it is possible.
#4 – Adding files directly to PDMWorks Enterprise-managed folders in Windows can put you on the hot seat.
Imagine this phone call to you at 8am on a Monday morning just as you arrive at the office: “Hi Jim, this is Bruce, VP of Operations at ACME Fab and I wanted to let you know that the PDMWorks Enterprise addin that you sold us is crashing PDMWorks Enterprise intermittently. All hell appears to have broken loose and I think we want our money back.” Those aren’t fun phone calls but you are prime candidate for one of those calls if you are adding / writing files directly to managed folders in Windows and relying on PDMWorks Enterprise’s hooks into Windows to add the files to the vault. File access permissions typically ensue depending on what SolidWorks Addins are loaded on the client and which way the end user is holding his or her mouth at the time. That is the extreme case though. The more common, though less severe, situation is where PDMWorks Enterprise and SolidWorks don’t crash but some of the files simply are not added to the vault (i.e. they are marked as a local file).
Solution:
Use a non-managed working directory (e.g. C:\MyPDMWEtempFolder\) to write your files to and then use the addfile API call from PDMWorks Enterprise to actually add the file to the vault.
#5 – Forgetting your assembly’s configuration file may cause heartburn.
If you have specified Settings in your project (accessed in VB through my.settings) or a specific version of the .NET Framework for your addin, then those items are persisted by Visual Studio in the configuration file located in your application’s execution directory. The file is usually named MyAssembly.dll.config where MyAssembly.dll is the filename of your Addin. If you don’t add that to the PDMWorks Enterprise vault along with your addin via the PDMWorks Enterprise Administration tool, then those settings will not be available to your addin while it executes on the client machine. If you have specified a setting, then chances are it is important to your application and will give you and/or your end users chest pains if they are missing.
Solution:
Add the MyAssembly.dll.config file to your addin (i.e. MyAssembly.dll) in the PDMWorks Enterprise Vault using the PDMWorks Enterprise Administration tool. PDMWorks Enterprise will download it at runtime to the same directory as your assembly.
There are numerous potential hazards to negotiate when writing a PDMWorks Enterprise Addin using .NET but those are my top five. I hope you find them useful and if you do, then please don’t hesitate to give me some blog love in the comments section. My ego is a powerful motivator to keep writing these articles : )
If you enjoyed this post, make sure you subscribe to my RSS feed!
Comments
9 Responses to “Who? Me?…PDMWorks Enterprise API Development Gotchas With .NET”
Got something to say?
-
My LinkedIn Profile
developed by Jhack
Jeff,
Thank you for the great post. The PDMWorks community isl greatly benefiting from your knowledge. Please keep writing for all of us.
Sylvain Trudel
Technical Sales Manager, PDM products
SolidWorks Corporation
Thanks Sylvain. I’ll keep writing if you keep reading : )
Jeff -
Great article.
Perhaps you can do a presentation at next years SWW ob the subject
Joy Garon
Sr. Education Specialist, PDM Products
SolidWorks Corporation
Hi Joy,
Thanks for reading. I would be happy to cover this at World next year if you think there is enough demand for this type of information.
Jeff
Thanks to Silvain’s tweet, I have found this article and added it to a currently-short list of .NET Interop resources on the Interoperability Forum: http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=3512468&SiteID=1
Jeff Says: Thank you orcmid. That is pretty cool.
Awesome post. I’m currently working on a PDMWE app and got caught by some of these….Thanks and keep up the good work…
Thanks Brian. I am glad I could help you out. If you have any good tips you would ever like to share then let me know and I would be happy to let you post.
Jeff,
I would agree with Joy. I think this would be a valuable presentation. Would you condiser presenting at a Users Group meeting in the future? This is valuable information. I am currently pursuing PDMWE as a solution and have stretched the capabilities of PDMWW and have reached it’s limit I think. Please feel free to contact me through my provided email address. Thanks
PJ
Thanks Phillip. Yes. PDMWE definitely steps it up a level or two from PDMWW. Workgroup is a good tool for what it was designed for but Enterprise is simply one of the most well-designed pieces of software I have ever used. It is almost up there with Winzip.
I would be happy to present this wherever people want the information. This is probably a little too specific for a users group or even a technical summit though. I think this is good for SolidWorks world and that is probably about it. I don’t think you will get enough people for such a specific topic at any other venu.
I didn’t make the cut at last year’s conference but here’s looking to next year : ). It is sounding promising based on the comments of the SolidWorks folks. I hope so because there really wasn’t enough attention given to PDMWe in terms of the number of presentations last time. We will do our best to fix that!
Thanks again for reading.