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 : )

© Jeff Cope for Extensible By Design, 2008. | Permalink | 9 comments | Add to del.icio.us digg
Who's linking ? Technorati BlogPulse Google
Want more on these topics ? Browse the archive of posts filed under .NET, COM, PDMWE, PDMWE API, PDMWorks Enterprise.

Copyright 2007 Extensible By Design. All rights reserved.

Writing Add-ins in SolidWorks can be tricky stuff as it involves class libraries, COM, interfaces, etc…  It can be argued whether it is easier or harder in .NET (ease of use of .NET versus pain in the rear of COM Interop) but your good friends at SolidWorks set out to make it easy on all of us by creating Visual Studio templates for quickly creating SolidWorks Add-ins.  The templates are packaged with the SolidWorks API SDK, support VB and C# and are analagous to having a SolidWorks part template that already has some geometry in it, custom properties, material assigned, etc…  When it was introduced back in the day, it was a Godsend.  It does have its issues from time to time though.  For some reason, I have had trouble deploying both on SolidWorks 2007 and 2008.  The SolidWorks API SDK installer runs without errors but when I attempt to create a new SolidWorks Add-in, I see this unfriendly message:

The I have spoken to a few other developers and concluded that I am not the only one so I decided to write a post on it.  Besides, I go through this everytime I have to reinstall SolidWorks, which is just often enough to be a real pain but not quite often enough for me to ever remember the steps to fix the issue.  I should admit then I am writing this as much for myself as I am for you.  Here goes…

 The Cause:

Based on the error message, you might get the impression that this is a trust or security issue.  That might lead you down a path of signing the dll with a strong name, configuring .NET security policy on your machine, etc… (i.e. the path to frustration).  To find the real cause, we must examine the Global Assembly Cache, GAC, to take a look at this SolidWorksTools dll file.  The GAC is where shared .NET assemblies are placed so that they can be made available to other applications.  On Windows XP, the GAC is located at “C:Windows\assemblies\”.  Taking a look at the GAC, we see that it contains a different version of the SolidWorksTools dll file than that which is expected by the SolidWorks Add-in Template for Visual Studio.  The version in the GAC is version 2.0.0.0 and not version 1.0.0.1, which is what the SolidWorks Add-in Template for Visual Studio is looking for.

 If we take a look at the template itself, then we can see where the version is specified for the SolidWorks Add-in Template for Visual Studio.  FYI, the template is contained in a zip file (SWVBAddin.zip for Visual Basic) which in turn is contained in the “…Templates\Project Templates\<Visual Basic or Visual C#>” folder of your Visual Studio 2005 directory.  Note:  I have Visual Studio 2008 but it is still in the box so I’ll let you know once I try it if the templates go in the same place. 

The zip file contains various bitmaps, icons, classes and modules as you would expect to see in an Add-in but it also a file called VBAddin.vstemplate which is a Visual Studio template file.  Once you open it, you see that indeed a different version of the SolidWorksTools dll file has been specified than the one which is installed in the GAC.  .

In theory, one should be able to update the VBAddin.vstemplate file above to refer to the insalled version of the SolidWorkTools dll file.  One of my favorite philosophers once explained why this might not work for me:

 ”In theory there is no difference between theory and practice.  In practice there is.”  – Yogi Berra

What I do is just to uninstall the SolidWorksTools dll file in the GAC (right mouse button on the file in the GAC and select uninstall) and replace it with the version 1.0.0.1 file that SolidWorks API support gave me the first time I ever reported this issue (a long time ago, in a galaxy far, far away…) .  You can do this by simply dropping the file in the GAC folder (e.g. C:\Windows\assemblies). 

Once you add the version 1.0.0.1 SolidWorksTools dll file to the GAC, you can go into Visual Studio and attempt to create a new SolidWorks project from the SolidWorks Add-in Template for Visual Studio.

And it works!  Now you can begin writing that Add-in (i.e. the one that is now a few days late while you fought with the SolidWorks SDK).

Note:  For any SolidWorks Add-ins that were previously compiling using the 1.0.0.1 dll, you will have to change your Visual Studio Project to reference the newer version.

 Good luck.

© Jeff Cope for Extensible By Design, 2008. | Permalink | 9 comments | Add to del.icio.us digg
Who's linking ? Technorati BlogPulse Google
Want more on these topics ? Browse the archive of posts filed under .NET, COM, SolidWorks, SolidWorks API.

Copyright 2007 Extensible By Design. All rights reserved.

 In spite of all their positive benefits, which are many, more than a few SolidWorks users look upon custom properties with the same disdain that a pre-schooler would have for green leafy vegetables.  You can explain the benefits of custom properties, how they help you find things, how they lead to healthy drawing title blocks, how they improve PDM implementations, etc… until you are blue in the face and with some individuals you still won’t make a dent.  There might be a change for a few days even a few weeks but inevitably you are back to files with no custom properties filled out. 

In order to increase the life-expectancy of CAD administrators everywhere, I have posted a free .NET Add-In for SolidWorks that will “remind” your users to enter certain custom properties whenever they create a new file or save an existing one (after the initial save).  The list of custom properties is configurable and

the user cannot proceed with their file until they enter the custom properties.  I am sure the program can be improved upon but for those without SolidWorks API skills of their own this should be a nice little app.  Also, for those who do have SolidWorks API skills using Visual Basic.NET, I am more than happy to share the code if you request it.

 The Add-In, called “Big Brother” is written for SolidWorks 2008 and targets the 2.0 .NET Framework, which means if you have SolidWorks 2008 installed on your machine then you can use it.

 To get started,

1.  Download the installer package for Big Brother from here.

2.  Run the installer, agreeing to the overly wordy license agreement on the way.

3.  After installing the software, run the “Register Big Brother.bat” file in the installation directory.  Running this batch file will register Big Brother with COM and add the appropriate registry entries for SolidWorks to load Big Brother when SolidWorks is run.

4. This is an optional step but if you don’t already have a decent XML editor, then I recommend you download XML Notepad which is a free XML editor from Microsoft.

5.  Use XML Notepad to edit the XML configuration files in the installation directory.  The installation has three XML files which are used to configure which custom properties are managed by Big Brother for each of the three main part types in SolidWorks.

• AssemblyPropertiesToManage.XML – Represents custom properties for assemblies.
• DrawingPropertiesToManage.XML – Represents custom properties for drawings.
• PartPropertiesToManage.XML – Represents custom properties for parts.

Edit the list of custom properties to manage for each document type using XML Notepad.  Each “ExtProperty” node represents a custom property.  PropName represents the name of the custom property to be managed.  PropValue and PropType should not be touched.  Leave those alone.  Save the file(s) when finished.

6.  Open SolidWorks and create a new part.  After selecting your template, you should be prompted to verify or fill in the values for the custom properties in your PartPropertiesToManage.XML file.  The same thing should happen for subsequent file saves.  The original Save (for new documents) doessnot trigger the FileSaveNotify event.  I suspect that it is triggered by the FileSaveAsNotify event.  If anyone tries that and gets the answer then please let me know.

7.   Additional configuration of the Add-In may be performed by editing the “ExtensibleEventManager.dll.config” file, which you should also use XML Notepad to edit. 

• If BigBrotherMode=True then it is mandatory that users enter values for all custom properties.  If BigBrotherMode=False then the dialog pops up as an FYI.
• If CatchFileNewEvent=True then files are managed on FileNew in addition to FileSave.

© Jeff Cope for Extensible By Design, 2008. | Permalink | 12 comments | Add to del.icio.us digg
Who's linking ? Technorati BlogPulse Google
Want more on these topics ? Browse the archive of posts filed under .NET, CAD, COM, SolidWorks, SolidWorks API, XML.

Copyright 2007 Extensible By Design. All rights reserved.

Excuse 1 -Visual Basic.NET is expensive unlike VBA, which is free.

Truth - Visual Basic.NET is included in the free Visual Studio 2005 Express offering from Microsoft.  It is a scaled down version of the pay version but offers most of the capabilities in the pay version.  You will be able to do just about everything you need to do with the SolidWorks API except develop SolidWorks Add-ins.  For around $300 US, you can get a hold of Visual Studio 2005 Standard, which has all of the features of the Express version plus a few more, including the ability to create SolidWorks Add-ins.

Excuse 2 – VBA is easier to use than Visual Basic.NET.

Truth – VBA has an advantage for very simple tasks but for more complex tasks, I think Visual Basic.NET has the advantage in the ease of use category.  Visual Basic.NET gives you access to the .NET Framework, a series of libraries that provide advanced capabilities for working with Windows, Windows applications, web applications and others.  The libraries that make up the .NET Framework are a significant improvement to the COM libraries that are available with VBA or Visual Basic 6.0.  Additionally, the development environment itself is improved over the VBA and Visual Basic 6.0 development environments.  Probably the biggest enhancement is the background compiliation error checking.  With this feature, Visual Basic.NET  alerts you to most errors as you type.  With the older VBA  environment, you found out about most compile errors only when you were brave enough to run the Macro.  With Visual Basic 6.0, you found out when you attempted to compile your application. 

 Excuse 3 – I will have to completely re-write all of my VBA Macros and Visual Basic 6.0 applications  in .NET if I want to use them with my .NET applications. 

Truth – Visual Basic has a conversion wizard that will convert Visual Basic 6.0 and VBA code to Visual Basic.NET.   It is often a good idea to re-write your VBA and/or Visual Basic 6.0 stuff for .NET in order to take advantage of the full power of .NET but it is optional.  Re-writing for .NET will also help you to better understand the different way that things are done in .NET but again, this is optional.  Additionally, if you have ActiveX controls written in Visual Basic 6.0 (or any language that supports COM) then you can “plug in” those components to your .NET application. 

© Jeff Cope for Extensible By Design, 2007. | Permalink | 6 comments | Add to del.icio.us digg
Who's linking ? Technorati BlogPulse Google
Want more on these topics ? Browse the archive of posts filed under .NET, COM.

Copyright 2007 Extensible By Design. All rights reserved.

 This Addin “listens” for Command Button events to be “fired” from data cards in PDMWorks Enterprise.  This could be File Cards (i.e. for existing files or folders) or Input Cards (i.e. for new files or folders).  If the command string of the Command Button matches our criteria, then the Addin will pull the next Serial Number from a Serial Number sequence in the vault.  The best thing about the Addin is that the Serial Number sequence name is specified as part of the command string.  This means that the Addin can be configured very easily by a non-programmer to run on any number of different Serial Number sequences.  In other words, our Addin is Extensible (sorry, I couldn’t resist). 

 Why Do I Need A Custom PDMWorks Enterprise Addin For Handling Document Numbers When PDMWorks Enterprise Already Has “Serial Numbers” Functionality That Handles This?

 PDMWorks Enterprise is a great tool and the Serial Numbers functionality is very useful.  However, as implemented in PDMWorks Enterprise, the Serial Numbers are kind of wired directly in to the system and don’t allow much flexibility in terms of when and how they are used.  You either set your part number to be populated from the Serial Number sequence or you don’t.  There is no “let’s do it this way for this case and another way for this other case.”  By writing a very simple Addin, we can set up our data cards to pull Serial Numbers when the user pushes a button of our choosing.  In other words, with a small amount of work, we allow the user to choose when to use a given number sequence.  I am tempted to say something here like “…and choice is good…” but I realize that not everyone will agree on that.  So I have decided to leave the freewill debates up to philosophers and priests while I tackle the PDMWorks Enterprise API.

I Don’t Want To Learn Anything, Can I Just Have The Finished Addin?

Yes.  You may download the compiled Addin from here.   However, you will still need to see the section below on deploying the Addin. 

Disclaimer:  No warranty is either expressed or implied for this Addin and the Addin is not in any way supported.  By downloading the Addin, you assume all responsibility for the Addin.How Hard Is This To Do?

Writing a PDMWorks Enterprise Addin is surprisingly easy although deploying them correctly can sometimes be a challenge.  This article does assume though that you understand the basics of  creating Addins with Visual Basic.NET.  If you haven’t yet mastered the basics of creating Addins with VB.NET then you can brush up with the fairly decent tutorial that is included in the PDMWorks Enterprise API guide. 

What Version of PDMWorks Enterprise Was This Addin Written For?This Addin was written for and compiled against PDMWorks Enterprise 2007.  However, you should be able to recompile it against PDMWorks Enterprise 2008 without much trouble.

 What Development Tools Do I Need To Write Such An Addin?

Visual Studio 2005 Standard is definitely sufficient for creating COM addins and you can usually pick it up in the US for $300.  Currently, that would be like 5 Euros for you guys across the ocean.    I haven’t tried it, but it may be possible to use the Visual Basic 2005 Express (aka “the free version”) to write this by manually adding the COMVisible<…> tags where appropriate in the Addin.  Although I am too lazy to install VB 2005 Express to test this out, I did go ahead an put the COMVisible<…> tags in their appropriate (at least by my reckoning) places.  If anyone tries this, I would be thankful if you could post your results for posterity.

Where Can I Find The Source Code For This Addin?

You can find the Project for this Addin, with all source code, in a zip file here.

 How Do You Do It (High-Level)?

1.  Follow the steps in the PDMWorks Enterprise API Guide to create a generic PDMWE Addin.  Note:  Yes I know this is cheating but it is getting late and I am starting to get pretty sleepy so I hope you will forgive the shortcut.  
2. Add a Serial Number sequence to your PDMWorks Enterprise vault.
3. Create a Windows Form in your application that will be used to provide the generated number back to the user.
4. Create or edit a datacard such that it has a Command Button to call the Addin.
5. Replace the generic OnCmd method in the generic Addin created at step 1 with an OnCmd method that accesses the next number in Serial Number sequence that is specified by the Command Button.
6. Debug endlessly until it “works” (on your machine)
7. Enlist a co-worker to test the Addin for you on their machine.  Note:  You can blame them later for inadequate testing coverage if the Addin doesn’t work properly : )

How Do You Do It (Detailed)?

1. Follow steps in API guide for creating a generic Addin.  (Sorry, you are on your own for this step) 
2. Add a Serial Number sequence (or two or three or four …) to your vault.  You will need to login as an administrator to do that. 
   • Note:  Just expand your PDMWorks Enterprise Vault node in the PDMWorks Enterprise Administration tool and then right-click on the “Serial Numbers” item in the tree.  You can then add as many serial numbers as you need.  I decided to create four in my example to handle the case where different departments number their documents differently.
3. Create a Windows Form in your application that will be used to provide the generated number back to the user.  In this example, the form is already created for you. 
4. Create or edit a datacard such that it has a Command Button to call the Addin.  You will need to set the Command type for the button equal to “Run Add-in.”  Also, notice the string in the “Name of add-in:” text box.  The string has the format of “Autonumber:<Serial Number sequence name>.  “Autonumber” is used to tell our Add-in which command buttons “belong” to it and the Serial Number sequence name tells our Add-in which Serial Number to pull the number from.  Make sure you save your changes.
5. Replace the generic OnCmd method in the generic Addin created at step 1 with an OnCmd method that accesses the next number in Serial Number sequence that is specified by the Command Button.  You will want to modify your error messages to be more user-friendly than mine before deploying your version of the Add-in.  In the interests of time, I opted to simply write out the exceptions to strings and return those, in their entirety, in messageboxes to the user.  This is okay for a blog article but probably not okay for production.
6. Debug endlessly until it “works” (on your machine)
   • There are detailed instructions in the PDMWE API Guide on how to debug an Add-in.  Oversimplifying, you just right-click the “Add-ins” item and then select “Debug Add-ins.”  You will then browse to your top-level assembly (.dll file).  When debugging, you do not need to specify the files referenced by your assembly (.dll file). 
7. Deploy the Addin
   • Right-click the “Add-ins” item and then select “Open.”  You will then browse to your top-level assembly (.dll file) AND its dependencies.  When running in Open mode, you DO NEED to specify the files referenced by your assembly (.dll file).  In this case, your top-level assembly (NumberGenerator.dll) references only Interop.EdmLib.dll.  This is the .NET wrapper for the PDMWorks Enterprise COM Library.
   • You will see a message telling you that you will have to Restart your machine any time you add a new version of your Add-in to the vault.  Note:  This is a real requirement and can cause much grief when you start developing applications that utilize numerous assemblies.
8. Test it “one more time” just to be sure.  By pressing the “Engineering Doc#” button on the File Card in the example below, I am able to receive a message from the Add-in telling me that a new number has been generated and that I can copy the number to the clipboard by selecting the “Copy” button on the form.  Note:  You could write to the file variable instead of the copy/paste method but it would not work for Input Cards as there is not yet a file on which to access variables.
9. 

Good luck.  Let me know if this article was helpful.

© Jeff Cope for Extensible By Design, 2007. | Permalink | 6 comments | Add to del.icio.us digg
Who's linking ? Technorati BlogPulse Google
Want more on these topics ? Browse the archive of posts filed under .NET, COM, PDMWE, PDMWE API, PDMWorks Enterprise.

Copyright 2007 Extensible By Design. All rights reserved.