For personal interest I wanted to install EMC Documentum to understand more about how it works, what development API and SDK is offered and how Documentum compares Sharepoint as they both overlap each other, in the document management marketplace. We are already a EMC development partner, integrating with the EMC Centera product, so went to the EMC developer area and I downloaded the Documentum Developer edition.
Documentum Virtual PC Windows 7 and Windows Server 2008
Running Windows 7 on my laptop I wanted to use this as an opportunity to try out the recently installed Release Candidate of virtual PC, that is now a component of Windows 7. I normally use VMWare Workstation. Although the specification requested server 2003R2, I installed a copy of server 2008 as it is so quick to install compared to 2003. I went to install Documentum and found I needed the Java engine installing, so I installed that. I guessed I’d need SMTP server and IIS and a few other obvious services running on the server to support the application, I enabled the key ones.
OK so the installer does indicate it is only for 2003 R2 server, but what the heck, mostly things work ok on 2008 that claim to be for 2003, I tried and failed to get the install to work due to various errors including too many service brokers. After a few attempts followed what I am supposed to do…
Server 2003 R2
I then installed the server 2003 R2, installing the supporting windows features and Java I expected I needed. I also enabled the client tools to allow me to link to the Documentum installer files on the client machine.
I attempted to run the installer from the client, but this bombed out half way through on the SQL server install. So I moved the installer to the VM system drive root. This time the install failed again. Finally I disabled client tools and the install then seemed to work. I guess client tools opens a terminal server RDP connection to the VM, mapping the local resources (clue in the \\tsclient\ mappings). Something in the installer didn’t like the RDP connection as disabling the client tools seems to have worked.
Now to start prodding it to see what I could do with Documentum and see what integration may be possible.
I am so glad I made the effort to go down to Manchester for the day to be inspired by Scott in a really well paced session on ASP.NET MVC – VS2010 / ASP.NET 4.0 goodness and finally a flash through Silverlight 3.
A few things came out of this day.
- Like other engineering professions, we have too few women.
- Developers smell better as the years go by.
- .NET is exciting the future is bright.
- Scott is very smart.
- The Spark programme is really getting developers thinking about starting software houses. Lots of buzz around this new imitative.
- General observation by many of how many iPhones are at a MS focused event.
- Manchester has changed a lot since I last had a walk around.
- Running from The Printworks to the Train at Piccadilly is further than you remember when the train leaves in 15 mins.
- There is so much you can do now, so few hours in a day.
Moving lap tops, desktops, operating systems or having a developer move on all cause issues with occasional items checked out to workspaces you have no control over.
There is a good blog post here on how to resolve these issues with the command line and TF.exe. You may remove workspaces or undo checkout locks on source code by using the commands outlined below.
Undoing a checkout that belongs to another user
James Manning's blog
The key command for my own reference is:
Had to use this today after finding a couple of instances of code checked out on my old vista installation but the files had been migrated to my new Windows 7 install. So undid the checkout finished the changes and checked in the new versions.
Directory path for prerequisites
For .NET Visual Studio installation projects, right clicking on the project in solution explorer for the setup project allows the properties of that project to be viewed.
In here is a button that allows the project prerequisites to be defined. When the setup project is built, it will produce a setup.exe and yourproject.msi.
Setup.exe is a bootstrap program, that is it can run some other things before your msi installer starts executing. Therefore customers should be advised to run the setup.exe, rather than the msi.
Most often in .NET programming this would be a check that the operating system to which you are installing the software is running the required .NET framework version and install it if it is found to be missing. What checks that setup.exe executes are defined with the above project prerequisites window. If a package needs installing, there are three choices from where the bootstrap can automatically load the package, a manually entered directory path, the path of where the installer is running from or by running it from the Internet. If install from installer path is chosen, the installer copies the package directory to the root of the complied setup project output. It gets the package from a package store elsewhere on the machine.
The path to the prerequisites central store is something I keep getting confused/forgetting between the times I set up the installer projects. So here is a reminder to myself. For my installation on VS2008 it is:
C:\program files\microsoft sdks\Windows\v6.0A\Bootstrapper\Packages
In here you find subdirectories for each package like the .NET framework that we may wish to install. Visual studio iterates through this directory when it shows the prerequisites to display the available packages.
In each of these package subdirectories is a products.xml file that defines the criteria for checking for the existence of the product on the machine and how to install it if it is missing.
It is easy to get one of these product.xml files and hack it to install your own package which is what we do to install media player for one of our products. You can find guides to doing this by searching for custom installer packages guide on search engines.