Aug 25, 2010
Filed under: #daxmusings #bizapps

We have been trying to push clients to use VSS (Visual SourceSafe) as much as we can on new projects, with minor success. For a client not used to development it is hard to convince them of the benefits.<div>It would be even harder to convince them on using TFS, since it requires even more setup. It is also a known fact that setting up TFS 2005/2008 is not something you want to do for your weekend amusement.</div><div> </div><div>That changes with TFS 2010. The setup is (pretty much) a breeze and in my testing I got TFS up and running in no time at all. I’m not convinced TFS is a good product for your average implementation, but for internal use or bigger projects, it is a pretty cool product.</div><div> </div><div>TFS 2010 may now be easy to setup, but the integration with Ax 2009 has some undocumented features.</div><div> </div><div>Here’s some unsolicited advice on things that took me forever to find.</div><div> </div><div>1. Despite what the “Using Ax 2009 with TFS” whitepaper may imply, there actually IS a way to get Ax to put its stuff in a sub-folder of your team project, namely by using workspaces. I found this clue in the whitepaper “Migration from VSS to TFS”… Unfortunately Ax uses the VS2008 client which means it does not support public workspaces (so you’ll have to set it up for each user separately).</div><div>2. Since Ax 2009 is “not certified” for TFS 2010 yet, it does not hook up to it out of the box. What you’ll need to do is install VS2008 with SP1, then install the hotfix from KB974558 (Visual Studio 2008 “forward compatibility”) which will allow VS2008 clients to connect to a TFS 2010 back-end.</div><div>3. Yes you can get the build to do the “combineXPO” trick. I duplicated the default build template, and in that workflow found the step where it calls msbuild. Delete the msbuild node, and replace with your own scripts. Removing msbuild saves you some serious headaches (errors on missing source files, trying to copy the final executable, etc). Also, the older tricks you will find by searching the web will not work anymore in TFS2010, you can no longer add xml commands into your csproj file, since most of the TFS properties (build number, droplocation, etc) are totally out of scope in 2010. In other news, I decided not to use the combineXPO executable linked to above, but made my own small VBScript (technically all you need to do is avoid duplicating header/footer information that is contained within each of the XPOs).</div><div> </div><div>There is some other (outdated) information on doing cool things with scripts, namely on MSDN, in the Ax4.0 section. I could not find this information in the Ax 2009 SDK at all.</div><div> </div><div>I’m currently looking into hooking up ax unit tests into the build process and getting detailed testing information reported.</div>

 

There is no comment section here, but I would love to hear your thoughts! Get in touch!