As we get into the build configs, you'll start to see why the set up of the appl config is so important. Just to remind you, check out:http://www.linkedin.com/groups/Build-Kick-Off-USTNSITE-Part-4574598.S.153410694?qid=06b10905-4eee-4f72-bce8-221eec8b1f44&trk=group_items_see_more-0-b-ttlAs we do have a development build and a live build I do have a copy of each appl file kept in each build due to the different names of the build locations. This is critical in:netwrk_bld = Z:/_CADDdev/Bentley/Standard/local_bld = C:/_CADDdev/Bentley/Standard/as defined in the appl cfg file.While splitting out the config files does make it easier for us to debug the build, the key to the ordering or the files is to make sure you have anything that can be overwritten from the standard build by client or project configs loaded first, and then fixed standard files last. Check out figure 3 in:http://communities.bentley.com/communities/everything_else_community/f/289/p/80292/221730.aspx#221730You'll get a better idea of how this works as we go.STD_10_Folders.cfgThis is where I set all my variables for the location of standard directories as they are used right throughout the other variables in the build. Some of these are the location for the site build:#---------------------------------------------------------------------------# Set Site Workspace Directories# #---------------------------------------------------------------------------SITE_WORKSPACE = $(base_dir)Site/$(STD_MS)/SITE_STDS = $(SITE_WORKSPACE)Standards/These are then used to set the location of the client and project build locations:STD_PROJECT = $(SITE_WORKSPACE)/Project/STD_CLIENT = $(SITE_WORKSPACE)/Client/ClientDir = $(STD_CLIENT)$(Client)/ProjectDir = $(STD_PROJECT)$(Project)/STD_20_Main.cfgThis is where I set all the standard variables for the builds. Cells, dgnlibs, guidgnlibs etc. STD_30_Vis_Vars.cfgFunny thingis I have quite a large viz build. So much so that I like to keep it in it's own cfg file, but you'd don't have to go that far.STD_40_Inclusions.cfgOK, time for some smoke and mirrors. In all seriousness, the include order of variables in this file is important to how you cascade your build. Remember, I don't use any pcf files and I only use the ucf files for minor additions set by the build. All of this is possible by this file. The first thing to do is include your 'Site' cfg files so that the office variables\tools are included:%if exists ($(SITE_STDS))%include $(SITE_STDS)*.cfg%endifNow that the office extras are included I look for a project cfg file:%if exists ($(STD_PROJECT)$(PROJECT).cfg)%include $(STD_PROJECT)$(Project).cfg_USTN_PROJECTDESCR = $(PROJECT)%endifThe reason I do this and not add a client cfg is that I need to keep the ability to be able to run the standard build for projects in a client area. In a lot of cases the <project>.cfg file will only have a few lines:Client = BHPBIO%include $(ClientDir)$(Client).cfgAny variables that I need in the project that are different to the client build can then be added.By following this flow of variables, what we have created is a build that delivers the standard build that can be overwritten or appended at the site\client\project level without the load order issues associated with pcf files. A very important key to me.What this does mean is that, from time to time, we may need to tweak client builds to have them work in our cascading environment. Once you get the hang of it it's not hard to do and means you can include your interface tools in every client or project environment. One very good way to help you manage this is to use 'named expressions' to turn off key components of the GUI, nice little hook for something we'll look at in future articles.
STD_50_Ref_Dirs.cfgThis file is used to set the location for all standard build reference directories.%if exists ($(Proj_Drv)COMMON/)MS_RFDIR > $(Proj_Drv)COMMON/%endif%if exists ($(CADDIR)00_RW/)MS_RFDIR > $(CADDIR)00_RW/03_Models/MS_RFDIR > $(CADDIR)00_RW/05_Common/MS_RFDIR > $(CADDIR)00_RW/12_Ref/%endifThe thing to be aware of here is that you don't use '='. The reason for this is that '=' is used to initially define a variable and all we want to do at this stage is append to MS_RFDIR variable. By doing this it means that no matter what is set in the standard\site\client\project configs, these paths will always be included.STD_60_Apps.cfgIn this files I set all my variables for the standard location and loads for mdl, vb etc. that are delivered with the standard build. Again, we don't use '=' as we always want these appended to the end of all other builds. This means we always have access to our standard delivered tools and means that we don't have to copy files into client and project build just to be able to use them.STD_70_User.cfgI like to make sure all my user data is located where I ant it, as such I have everything I need in this cfg file. First thing to do is set the location of user files:%if exists (C:/Apps/User/$(USERNAME))STD_USER = C:/Apps/User/$(USERNAME)%elseSTD_USER = H:/Bentley/%endifNow I'll set that user variables based on the ucf file existing in this location. For all of my users, this area is located and populated by the batch files run from the hta on run or from login scripts:%if exists ($(STD_USER)$(USERNAME)_$(STD_MS).ucf)_USTN_HOMEPREFS = $(STD_USER)_USTN_USERNAME = $(USERNAME)_USTN_USERCFG = $(STD_USER)$(USERNAME)_$(STD_MS).ucf_USTN_USERINT = $(STD_USER)_USTN_USERINTNAME = $(STD_MS) _USTN_USERINTROOT = $(STD_USER)$(STD_MS) _USTN_USERDESCR = $(USERNAME) _USTN_USER = $(STD_USER)%endifNow to set the location and naming for other files, including a user AccuDraw text file and a user guidgnlib file:%if exists ($(STD_USER)accudraw_$(STD_MS).key)MS_ACCUDRAWKEYS = $(STD_USER)accudraw_$(STD_MS).key%endifMS_USERPREF = $(STD_USER)$(USERNAME)_$(STD_MS).upfMS_FKEYMNU = $(STD_USER)personal_$(STD_MS).mnuMS_GUIDGNLIBLIST > $(STD_USER)$(username)_$(STD_MS).dgnlibMS_DOCKINGPREF = $(_USTN_PREFNAMEBASE).DOCKING.$(STD_MS).xmlMS_TASKDIALOGPREF = $(_USTN_PREFNAMEBASE).$(STD_MS).TSKNAV.xmlMS_GROUPPANELPREF = $(_USTN_PREFNAMEBASE).$(STD_MS).GroupPanels.xmlBB_TASKDOCKINGPREF = $(_USTN_PREFNAMEBASE).$(STD_MS).task.xmlMS_BUTTONMENU = $(STD_USER)$(USERNAME)_$(STD_MS).BTNMENU
STD_80_Locks.cfgThis last file in the list is a VERY handy little addition and has fixed a LOT of headaches for me. I've always had issues with users being able to edit variables via the menus in MicroStation and trying to lock variables in builds is always a pain as you want to lock them in the standard build, but be able to edit them in client and project build. Well, fear now more. The beauty of the load order with these cfg files and the way we cascade the inclusions means we can run this last file to lock and and all variables, if that's what you want, which means that they cannot be changed from within MicroStation:%lock MS_RFDIR%lock MS_SEEDFILES%lock MS_DESIGNSEED%lock MS_DESIGNMODELSEED%lock MS_HIDE_LIBRARY_SOURCE_NAMES%lock MS_PLTDLG_FORCEOUTDIR%lock MS_PLTFILES%lock MS_PENTABLE%lock MS_BATCHPLT_SPECS%lock MS_BATCHPLT_JOBSET_DIR%lock MS_PLT_SET_UNITS_FROM_SHEET%lock MS_PLTFILE_EDITOR%lock MS_GUIDGNLIBLIST.%lock MS_DGNAPPSShort of locking permission access to all ucf files, you'll never stop the fiddlers, but this means that the 90% of those who will play from within MicroStation are now locked out. A major time saver when it comes to build and user support.Well, got a headache yet :-) I know this does seem like a lot to digest, but a few basic principles in this article are going to change the way you deliver company builds. We're not finished just yet as we can now look at how we add the builds for our other apps like Structural Modeller, AECOsim and more, but there's a lot to digest to start with so.........More soon.