Monday, October 15, 2007

Associating DWG files with Solid Edge

Solid Edge does not associate itself with DWG files or any other neutral file format by default. You can however create this association yourself by following the steps below.

  1. In Windows Explorer (not Internet Explorer), click on the Folder Options command found under the "Tools" menu.
  2. In the Folder Options form, click on the File Types tab.
  3. Depending on whether another product is installed that associates itself with DWG files (like AutoCAD) or not, you may or may not already have an entry in the "Extensions" column for "DWG". If you do, click on the entry. If you do not, click on the "New" button and type in "DWG" in the File Extension field.
  4. On the FileTypes tab with DWG highlighted, select the Advanced button.
  5. If no Open entry exists select New... If it does exist, highlight it and select Edit...

  6. In the resulting form, make sure the Action field states "Open" and the Application used to perform action: field states "C:\Program Files\Solid Edge V20\Program\Edge.exe" "%1"

  7. Check the "Use DDE" option. In the Application: field type "Edge", and in the Topic: field type "System".

  8. Select "OK"

  9. Select "OK"

Sunday, October 14, 2007

Solid Edge V20 Deployed!

I have finally gotten Solid Edge V20 and the Viewer deployed through my organization on Sept. 27th. We deploy SE to over 100 users and the Viewer to over 400 users across about 10 geographic locations in one night over a couple hours. All went well considering this was the first deployment since the new Packaging Specialist started, and it was done on a brand new version of the deployment system we use.

We use Microsoft's System Center Configuration Manager (SCCM) which was just upgraded from SMS 2003. It allows inventorying PC's throughout the org, as well as pushing software to the PC's. To be able to push the software, you must use the MSI supplied by Solid Edge and repackage it as an EXE. Since the MSI is used, you must also install .NET and ISSCRIPT separately (which can also be added to the EXE package). We found that the ISSCRIPT.MSI must be modified to work with SCCM due to the fact that it installs an IDRIVER.EXE that runs as the interactive user (the logged on user) rather than the launching user (the SCCM client) which causes the SE install to fail under SCCM.

In any case, it all went smoothly, and the only issues we had were due to a couple individuals that just got missed during the upgrade. They were easy to identify since we use Insight and the server would no longer allow them to connect since it had also been upgraded (by hand).

Now all I have for a while are Service Updates, which are really easy.