Testing...1, 2....testing

As you build a shared network "production" environment it is important to realize that multiple people are relying on that environment at any given time. Making the smallest change to production code can seem elementary and you will be tempted to just edit the production environment. There is no need to live on the edge and to get your heart pumping in anticipation as you open a production network file, edit one line of code, and click save.

Why put yourself through this stress? Setup a development network environment to test all of your changes before pushing it to the production environment. Editing one line of code invites room for error- an omitted semi-colon or a missing closing parenthesis are common simple oversights that can be caught immediately in the development environment to ensure a streamlined deployment into production.

To create a development area create a mirrored folder structure of your production environment. I create a dev folder at the same level as the production network folder. Inside of the dev folder is a copy of all of the production sub-folders and files.

Let's go ahead and create a new .arg (user profile) from AutoCAD for our development environment. Before doing this delete the .arg file that was copied into the _dev\Profiles folder. Open the production user profile in AutoCAD and we will create a new profile from the production profile. When the new profile is created we want to change the Enterprise Menu file location to point to our dev folder:

Now we can Export this development profile to our _dev\Profiles folder.

Depending on how you choose to manage your paths we may need to update a few lines of code in the .mnl file. Remember the .mnl file located in the same folder as the CUI will load automatically. The highlighted segment is what I changed.

;Title: SLD_dev.mnl

;Description: Automatically loads when SLD.cui is loaded.

;Constants

(setq SLD_DRIVE "X:\\")

(setq SLD_PATH (strcat SLD_DRIVE "SLD_dev\\Support\\"))

(setq SLD_TOOLS (strcat SLD_PATH "SLDTools.dll"))

;Load custom routines

(command "NETLOAD" SLD_TOOLS) ;netload sld functions

(load (strcat SLD_PATH "sld.lsp")) ;load lisp files

(princ "\nStreamlined content loaded!\n")

We can now update our desktop icon (in the _dev folder) to point to the development .arg file by changing the folder path and file name:

You can rename the development desktop shortcut so when you copy it to your desktop it will not be confused with the production environment.

Now we have two side by side environments, one that is production which is shared with your designers, the other which is identical to production but can be used for testing. When AutoCAD is launched from the development icon it will create a new profile so you can have both profiles loaded on your machine.

Any new custom files (lisp or dll) can be modified, created, and tested in the development area first. Also, CUI edits can be done in the development area before being visible to everyone. The CUI content will not be using hard paths so as long as it is relying on AutoCAD support paths then it will function fine when transferred into the production environment.

This post is really meant to cover the concept and importance of using a test environment. To what degree and exactly how to set up an efficient test environment may vary.

A Streamlined Access Point For Custom Content

One of the key concepts to understand when customizing AutoCAD (especially in a network environment) is that any CUI that is loaded into AutoCAD (either the Main CUI or the Enterprise CUI) will automatically load a menu lisp file (.mnl) that is in the same folder and shares the same name as the CUI file.

This is an excellent access point to provide custom content for your AutoCAD user profile. For example, if you create an AutoCAD user profile (.arg file) and path the EnterpriseMenuFile to a custom CUI then you can also create a .mnl file with the same name and in the same network directory.

In the .arg file the CUI paths are defined as follows:

"EnterpriseMenuFile"="x:\\sld\\support\\sld"

"MenuFile"="%RoamableRootFolder%\\support\\acad"

This profile will automatically look for a .mnl file with the same name and in the same directory as the CUI: 

Inside the .mnl file you can add in pretty much any custom content that you want. The below code will netload a dll file created in C#.net and will also load a lisp file.

;Title: SLD.mnl

;Description: Automatically loads when SLD.cui is loaded.

;Constants

(setq SLD_DRIVE "X:\\")

(setq SLD_PATH (strcat SLD_DRIVE "SLD\\Support\\"))

(setq SLD_TOOLS (strcat SLD_PATH "SLDTools.dll"))

;Load custom routines

(command "NETLOAD" SLD_TOOLS) ;netload sld functions

(load (strcat SLD_PATH "sld.lsp")) ;load lisp files

(princ "\nStreamlined content loaded!\n")

With this access point the amount of customization you can add is virtually endless. The nice thing is if you develop a new function and load it into this .mnl file it is instantly available to all of your users...that's streamlined.

Creating an AutoCAD User Profile

Creating an AutoCAD user profile allows AutoCAD to be "customized" in order to function efficiently within an environment. A few examples of data that is stored in an AutoCAD profile are support paths and plotter paths such as the location of .ctb files. Additionally, some of the most important elements in an AutoCAD user profile are the Customization (CUI) Files.

There are two primary CUI files, Main and Enterprise. The difference between these are that Main is editable by the user while the Enterprise CUI file is read-only by default. This makes the Enterprise CUI a great choice for providing customized content to your users through a shared network CUI file.

To create an AutoCAD user profile that points to your network CUI file we will start in AutoCAD. Select Tools | Options | Profile Tab | Add to List and enter a new profile name.

Click Apply & Close and then select the new profile and click Set Current. Your new profile should be highlighted and should show up as the current profile.

Select the Files Tab and point the Enterprise Customization File to the network cui file that you will be using. (Note: You can use UNC instead of a drive letter if you do not have a common network drive map for all users).

There are several other paths, settings, and configurations that can be controlled by the AutoCAD user profile but we will only change our Enterprise CUI for now.

Let's now export this profile so we can place it on a network file server making it available to all users. To do this go back to the Profiles tab and click Export. This creates a single file with an .arg extension. Once this .arg file is on the network we need a way to load it into AutoCAD. For this we can create an AutoCAD desktop icon that will load the new profile.

Copy an AutoCAD desktop shortcut into a network location (we can share this new shortcut with all users).

Right click on the AutoCAD shortcut and select Properties. We can now point to the .arg file using the /p (profile) parameter on the Target line.

Note: the /p goes after the acad.exe parameter that is already in the Target line. The full target line now looks like this:

"C:\Program Files\AutoCAD 2010\acad.exe" /p "X:\SLD\Profiles\SLD.arg"

This AutoCAD shortcut can be re-named and copied to each users' desktop and double clicking it will load the new profile you created!

The beauty of this approach is you do not need to modify anything on the users' machines, just simply copy the shortcut. You can automate the process of copying the shortcut to their desktops several different ways. The method I use is a batch (.bat) file that can be executed through a hyperlink on a web based collaboration tool such as SharePoint. This allows any user to get any profile (desktop shortcut) on to their machine with a single click.

You can make as many .arg files as you need depending on unique client needs, vertical application needs, or discipline needs.

With the core structure of our AutoCAD environment in place we have set the stage for endless customization possibilities. Next we will talk about loading an .mnl (menu lisp) file along with the CUI file and how this can be the key to providing all sorts of customized apps to your users.

The Foundation For a Streamlined Design Environment

While at a software conference last year that happened to be at a casino, I chose to partake in a little card playing. I am not an experienced gamer but a friend had recommended that I try Pai Gow poker. This game offers some flexibility in how you can play your hand depending on how aggressive you want to be. I found myself faced with a particularly tricky hand that could be played a few different ways. The dealer, noticing my indecision suggested a basic rule and informed me that this is what "the house" would do. The rule seemed simple and my initial reaction was that more thought should be put into it. But, I glanced around at the thousand dollar chandeliers hanging above each table and said, "well, the house seems to be doing pretty good".

The point being - simple can be effective and when it seems a situation should have more thought or effort put into it, ask yourself if there really is a benefit or is unnecessary complexity being added?

Laying down a simple "out-of-the-box" foundation is a great start to building an AutoCAD based network environment. Don't get bogged down trying to figure out how to deploy a specific menu, profile, or custom app - this (and more) can all be added later and if you have a stable, robust foundation in place it will be much smoother to work with.

Having a network deployment image for out-of-the-box AutoCAD local at each office is one of the most helpful and basic tools for maintaining a streamlined design environment. To create a network deployment image refer to the AutoCAD Network Administrator's Guide.

There are several options that can be built into the network deployment image. I always leave it as a silent install and out-of-the-box (except for licensing, see below). This will provide a flexible base platform that will allow for customizations to be added post-install. So instead of maintaining multiple network deployment images, start with a common base that can be used as a starting point for everyone.

Depending on how your AutoCAD license agreement is setup you may want to add the license server as a Windows Environment Variable in your network deployment image. You can use a batch file (and reg.exe) to modify the Environment Variables later on (i.e. for different offices or if your license servers change).

I will share some techniques that I use to deploy (and maintain) different user profiles in upcoming posts.

Welcome

Welcome to ‘Streamlined Design’, a blog dedicated to administrators and designers working with AutoCAD based products. I’ll be using this blog to share strategies for administering design technologies in a network environment, customizing AutoCAD, and interfacing different AutoCAD based applications.

There are several different methods to deploy and administer AutoCAD and I certainly do not claim to have all the answers nor that I have found the absolute best practices. I feel a design environment can always be improved…further streamlined. With that in mind, I will share some strategies and techniques that have worked for me and I hope during the process of doing so that I will continue to learn more about what I enjoy doing.

A little about me…I have worked with AutoCAD and several different AutoCAD vertical applications since the mid 90’s. I am responsible for administering a design environment that consists of multiple designers, multiple offices, component databases, and a handful of different AutoCAD based applications. I found that I really enjoy customizing AutoCAD and over the past few years I have been focusing on using C#.net to develop AutoCAD based applications.

Please feel free to contact me or suggest alternative methods as replies to any post. Thanks for reading!