API development and customization is all about automating repetitive tasks and I am sometimes amazed at how much I have been able to do over the years to make end users’ daily tasks easier to accomplish.  One place I have fallen short, however, is automating my own repetitive development tasks.  That is why decided to create a Visual Studio Template to automate the creation of PDMWorks Enterprise Addins.  This is similar to the SolidWorks Software Development Kit offered by SolidWorks for developing SolidWorks Addins.

For those of you who may not be familiar with Visual Studio Templates, they are very similar to SolidWorks Templates.    Within SolidWorks Templates, you store things like unit information, material information and dimensioning standards information.  Within Visual Studio Templates you store References, source code files (e.g. classes, modules, forms, etc…) and the like.  Hitherto, if you wished to create a custom PDMWorks Enterprise Addin, you would create a generic Visual Studio Class Library, add a reference to the PDMWorks Enterprise Type Library (i.e. EDMLib), add a class file that implements the IEdmAddIn5 interface and then add your custom code to the GetAddinInfo and OnCmd event handlers.  With the PDMWE Addin Template, all you have to do is select the PDMWE Addin template from Visual Studio’s New Project dialog.  All the files and references are added automagically.  It is ready to go and all you have to do is add your custom code to the GetAddinInfo and OnCmd event handlers.  There is already some custom code there to for your reference.  Currently, the Template is only available for Visual Basic but if some C# developer out there wants to send me a stubbed out PDMWorks Enterprise Addin written in C#, then I would be happy to package it into a Visual Studio Template.

This is going to save me a lot of time and I hope it will save you a lot of time too.  I also hope it saves SolidWorks API Support a lot of time so that they can spend more time on my Service Requests : )  I guess on one level it is not so bright of me to make this thing public as it will also save time for my competitors in the PDMWorks Enterprise API Consulting world.  It seemed like the right thing to do though considering all of the help that people have provided me with over the years.  I hope you enjoy it.  As always, if you use it, then I ask that you leave a comment with your feedback.  It is a small price to pay.

 

Installing The PDMWorks Enterprise Addin Template

1.        Download the installer from here and unzip it.

2.       Run the installer.  You should see these screens:

  

Note:  The Addin Template will only be installed for the releases of Visual Studio that you have installed.  Visual Studio 2005 and 2008 are supported.  If the installation is unsuccessful, then you can follow the manual installation steps below.

 

 Finished!  Now you are ready to create your first Custom PDMWorks Enterprise Addin using the PDMWE Addin Template.

 

Creating Your First Addin With The PDMWE Addin Template

1.         Launch Visual Studio. 

2.       Select Create Project from the Start Page or File, New, Project from the toolbar.

 

 

3.        Select PDMWE Addin from the New Project dialog’s Visual Basic folder.

 

 

4.        Provide a name for your new Addin and press the Ok button.

 

A new Addin is created for you with a functional PdmweAddin class and a reference to EDMLib.  The Addin is functional as is and may be compiled and debugged before adding any additional code if you want to try it out. 

 

 

 Enjoy!

 

 

Manual Installation Steps For A Failed Installation

 

1.        Go to the installation folder (C:\Program Files\Extensible CAD Technologies\PDMWE Addin Template\ is the default) and find the PDMWEAddin.zip file.

 

 

2.        Copy the PdmweAddin.zip file to your Visual Basic Project Templates Folder .  By default, this folder is located at My Documents\Visual Studio 200X\Templates\Project Templates\Visual Basic

 

  

You should now be ready to go!

 

Uninstalling The Template

 

To uninstall the PDMWE Addin Template, simply find “PDMWE Addin Template” on  Add/Remove Programs and uninstall it from there.

© Jeff Cope for Extensible By Design, 2008. | Permalink | No comment | 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, PDMWE, PDMWE API, PDMWorks Enterprise.

Copyright 2007 Extensible By Design. All rights reserved.

Over the past few months I have received numerous emails from folks using the original PDMWE Number Generator.  It is such a simple little app that I was pleasantly surprised at all of the nice feedback people gave me regarding it.  To show my appreciation, I have modified the Number Generator to allow it to work with multiple serial number sequences ”on the fly.” 

 You have always had the ability to set up muliple serial number generators in PDMWorks Enterprise but now the user can decide at File/Folder creation time which serial number to use.  An anticipated use case with this improved version of the tools is for users who have multiple categories of parts with numbers being assigned by category.  Note:  Even though the functionality has been expanded, the tool is still very easy to install and configure. 

So how does it work?

The Number Generator is a PDMWorks Enterprise add-in that runs whenever a user presses a command button (from a data card) that is configured to “call” it.  The Number Generator downloads the latest copy of the ListItems.xml file from your vault’s Options folder and checks it for List Items.  Each <ListItem> element in the XML file has a <Name> element and corresponding <Value> element.  The <Name> elements represent what the users sees in the Number Generator’s drop-down list and the <Value> elements represent the Serial Number sequence that is “called” whenever a user selects that item from the drop-down list.  There is no reasonable limit to the number of serial number sequences that can be supported by the Number Generator.  Just add a new <ListItem> node to the ListItems.xml file, being careful to type the exact name of the Serial Number sequence in the <Value> node.

 Don’t be afraid of the xml.  It is really simple.  Here is the xml file that was used to develop and test the Number Generator.  Notice that the text contained in the <Value> nodes of the ListItems are an exact match for the names of the Serial Number sequences in the vault.

Alright…  Ready to get started?  Good.  Here are the high-level installation and configuration steps:

1. Download and unzip the file containing the tool.
2. Create any desired serial number sequences using the PDMWorks Enterprise Administration Tool. 
3. Add the included add-in to the PDMWorks Enterprise Add-ins using the PDMWorks Enterprise Administration Tool. 
4. Using Notepad or (better) an XML editor such as XML Notepad, edit the ListItems.xml file that is included in the Options folder to include your desired serial number sequences.
5. Copy the included Options folder to the root of your PDMWorks Enterprise vault.
6. Checkin the ListItems.xml file, if not done automatically.
7. Give all users Read Only permissions to the Options folder.
8. Add a command button to any data card you wish to run the Number Generator from and configure the command button to “call” the Number Generator.
9. Test it out and if it works well for you, then add some nice feedback to this post.  Otherwise, curse me under your breath and keep it to yourself.

Here are the detailed steps:

1. Download the file containing the tool from here.  Unzip it once it is downloaded.  It should contain two dll files (Interop.EdmLib.dll and NumberGeneratorForPDMWE2008.dll) and an Options folder which in turn contains a single xml file (ListItems.xml).
2. Create any desired serial number sequences using the PDMWorks Enterprise Administration Tool.  Keep track of the names of the Serial Number sequences as you will need this information for step four.
3. Add the included add-in to the PDMWorks Enterprise Add-ins using the PDMWorks Enterprise Administration Tool.  Use the New button to add the Add-in’s dll files to the vault.  Make sure you select BOTH dll files to add.  Don’t worry about the warning message that PDMWorks Enterprise gives you after you add the dlls.  The warning message is just letting you know that you have to reboot when updating the same Add-in to a later version.  I changed the name of this add-in from the previous version so that won’t be an issue here.
4. Using Notepad or (better) an XML editor such as XML Notepad, edit the ListItems.xml file that is included in the Options folder to include your desired serial number sequences.  Notepad can be used but I am partial to XML Notepad as seen below.  XML Notepad is a totally free utility from Microsoft and can be downloaded from here.  If using Notepad, be very careful to preserve the format of the XML file.  Each <ListItem> element tag must be closed by a corresponding </ListItem> element tag.  The same goes true for the <Name> and <Value> element tags. 
5. Copy the included Options folder to the root of your PDMWorks Enterprise vault.  I want to emphasize the “to the ROOT of your vault” part of that.  If your vault’s local view is found at “C:\PDMWE\MyVault” then your Options folder should be found at “C:\PDMWE\MyVault\Options.”
6. Checkin the ListItems.xml file, if not done automatically.
7. Give all users Read Only permissions to the Options folder.
8. Add a command button to any data card you wish to run the Number Generator from and configure the command button to “call” the Number Generator.
9. Test it out and if it works well for you, then add some nice feedback to this post.  Otherwise, curse me under your breath and keep it to yourself.

You can hit the “Copy” button to copy the auto-generated number to the clipboard.  You can then paste it anywhere you want (e.g. filename, data card variable, etc…).

 If you or someone you know use(s) this thing and find it helpful, then give us a holler in the comments section below.  Thanks.

© Jeff Cope for Extensible By Design, 2008. | Permalink | No comment | 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, PDMWE, PDMWE API, PDMWorks Enterprise, XML.

Copyright 2007 Extensible By Design. All rights reserved.

One of the nice things about not being employed by Microsoft is that I need not live in fear of receiving an email like this from Bill Gates.  This email from Bill Gates to the people responsible for Windows is worth a read if you have time.  It is a nice little rant on Windows from the guy most responsible for making Windows the most ubiquitous operating system on the planet.  The next time you get ready to verbally abuse Bill Gates when Windows frustrates you, take a deep breath and relax with the knowledge that BIll is using the software too and giving ‘em hell when it needs to be improved.

 

Note:  The Microsoft Mullet and other funny mullet pictures can be found at http://www.mulletmadness.com/.

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

Copyright 2007 Extensible By Design. All rights reserved.

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 | 4 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.