Notes about my experience in setup of Microsoft Dynamics AX 4.0 integrated with Microsoft Visual Source Safe.

Having in mind that, according to “what’s new“ document, the main focus in improvement of development tools in Axapta 4.0, was to support larger development organizations with multi-site development, I made an assumption that version control integration is probably one of the most important advance in development tools in the new version of my favorite Microsoft product. So, I started my acquaintance with Microsoft Dynamics AX 4.0 from setting up its new and so long-awaited feature – VSS integration. In this blog I will not repeat setup instructions, I just would like to share my first experience in setup and configuration of Microsoft Dynamics AX 4.0 and its build-in Visual Source Safe (VSS) integration.

In my configuration scenario I have one common AOS server, one common SQL server and one VSS server installed on the same physical box. Also, one Team Server installed on another box. Separate Axapta client was installed on each developer’s machine together with VSS client of course. Also, separate repository folder was created on each developer’s machine, as it is required by installation documentation. In general it wasn’t difficult to setup VSS integration and to configure all client machines. But there were a few obstacles and nuances which I would like to draw your attention to. First thing that you should have in mind before you start your own installation of Axapta 4.0 integrated with VSS, is that new version of Axapta works only with new version of Microsoft VSS! Only Visual Source Safe 2005 is supported. If you already have for example Visual Source Safe 6.0 installed you will need to upgrade it before using it with Axapta 4.0. Otherwise you will end up with error saying: “VSS Connection Error”.

I have seen it as a common mistake of some other developers who first time tried to configure Axapta 4.0 with VSS, since in my opinion, it’s not quite clear from the error message why VSS can’t be connected and there is not so much attention in the official documentation to the fact that only new VSS is supported.

When you have upgraded your version of Microsoft Visual Source Safe and successfully connected Axapta with it, another installation step needs to be performed – setup and connection to the Team Server. By design, Team Server instance has to be installed on the separate machine then AXDB SQL database and AOS server. In my installation scenario I have separated them as well. But if you have installed everything on the same box and Infolog with error: “[Microsoft][ODBC SQL Server Driver][SQL Server]Cannot open database requested in login 'AXTS'. Login fails” appears - try to solve this issue, by manually creating NT AUTHORITY\NETWORK SERVICE user on that box to have all services working together. Also, make sure you have SQL, which holds Team Server’s database, with Windows authentication turned on like it shown on the picture:

After installation of Team Server, new local user group needs to be created on the Team Server’s computer. This group should be granted with access to the AXTS database which was created during Team Server installation process.

Next step of configuration of Team Server is setting up its authorized users. Each developer’s computer that has AOS installed must be added as a user on the Team Server. It means that you have to add AOS holding computer names to that new user group created on the machine running Team Server. To do so, you have to go to “Computer Management/Local Users and Groups/Groups”, find your team server group and add your AOS holding computers like it shown on the picture:

When all previous steps are completed and you have successfully installed all necessary components you need to add your label file to the VSS version control system and create repository of objects on your local hard drive and also add them into VSS database. Before you do so, you need to create local folder which will hold repository and setup VSS parameters in Microsoft Dynamics AX client.

In order to create repository folder simply open windows explorer and create new folder, for example “C:\REP”. Then go to Tools/Development Tools/Version Control/Setup/System Settings and set your VSS integration parameters. Setting of parameters is quite simple and self-explanatory. Just enter your VSS server and Team Server settings in the appropriate fields and press apply. Then you will have to confirm that you would like to change your global development settings and system will create VCSDef.xml file and will add it to the VSS database.

Now, we are ready to create label file. Go to Tools/Development Tools/Version Control/Setup/Create Label File. In the form shown, type some description for VSS history records and press OK. After that one problem that could appear is: “Error Message Unable to flush the label file.” This can happened when NETWORK_SERVICE account doesn’t have permissions to rename files in the application folder. The thing is, when label file should be flashed, AOC is writing everything in to an .alb file and then tries to rename it to standard .ald and if it doesn’t have permission to do so, error appears. To fix this, add NETWORK_SEVICE account to the application folder with appropriate permissions.

Creation of repository is one time action needed to complete setup of Axapta 4.0 with version control system. Microsoft Dynamics AX 4.0 application consists of four application files for each layer: .aod file which contains business logic and other three files which contain documentation and labels. New version control system management integrated with MorhX development suit allows to include all these parts of Axapta application into version control system. To put business logic into the version control system, it was split into many small XPOs. The smallest, atomic piece of application has been chosen to be an object. It means that even if we have updated only one method within a class, whole class will be updated in the VSS. All these XPOs have standard native export format for MorphX and needs to be exported from the application in order to include them into version control system. That’s why, when you first time installing Axapta 4.0 with version control, you need to create repository by exporting all objects from your current layer and adding them into the version control database. The process is rather simple, but could be quite time consuming depending on size of your layer. I haven’t had any difficulties creating my repository. So, if you just follow those simple steps described in the “what’s new” document, I believe you wont have any difficulties as well. Go to the “Tools/Development Tools/Version Control/Setup/Create Repository”, in the shown window add small description for the history and press OK.

All other Axapta clients installed on different machines don’t need to follow the same procedure to create repository, they just need to get synchronized before they start their work.

The last thing you should pay attention to, before you start using VSS integration with Dynamics AX 4.0 is Best Practice Settings from Version Control Configuration window. There you can set an acceptable level of quality allowed for check-in.

It seems to be very cool feature, but I was a bit disappointed by the fact that system didn’t allow me to setup different levels of diagnostic level for the compiler.

Whatever level I have set in the compiler setup window, when I try to check-in my objects, system has automatically changed that setting to the highest, level 4, and didn’t allow me to check in if errors/warnings were found. Moreover this setting was never changed back to the level I had in my configuration before I do check-in, so I had to remember to change it back myself when compiling my application next time. This was very annoying and at the end we decided to turn off best practice bar at all.

One more issue I have noticed was when I started to work with labels. The thing is, when you have created new label in multilingual environment, system doesn't see this label even though this label exists in the ".ald" file! Only when you have your client restarted you will see your label. Until then, for Axapta, this new label will exist only in the label log and not in the ".ald" which will also cause a best practice error when you try to check-in your object with new label set in the its properties.

Well, in spite of all these small issues, setup was not difficult and my team and I were very happy with new feature of Microsoft Dynamics AX 4.0 - Visual Source Safe (VSS) integration. It really improves whole product development life cycle and brings development process on the next level of teamwork. I would definitely recommend you to start using VSS integration.