Dexterity Source Code Control Server 2010 with Windows 7

Patrick Roth - Click for blog homepageSupporting Web Services and Workflow in Dynamics, my primary desktop machines have been Windows 2003 for a number of years.  Of course Vista was out of the question because GP Web Services would only install on a server OS.

When Windows 2008 was released I had considered upgrading my OS but honestly didn't want to go through formatting my machine and reinstalling everything again for the sake of having an updated operating system.  Yes, I was being a bit lazy.

I just received my new machine recently and with GP 2010 that went to RTM a few days ago and Web Services supported (for test & development) on Windows 7, I took the plunge and had IT deliver it with Windows 7 Enterprise 64 bit installed.

Coincidentally, David Musgrave said he was having issues with Dexterity 2010 and Dexterity Source Code Control Service (DSCCS) and I thought I'd look into this as I set my new machine up.

Dexterity installed without issues and DSCCS also was appearing to install OK as well until I ran into my first issue.

Here, for our projects we use a VSS database that is created on a network share that IT owns.  It is fully backed up (or so they tell me - never had to find out otherwise) and we've used it since at least 2001.

In the install, the Dexterity Source Control Server window prompts me to choose the Provider of either Generic or Microsoft Visual Source Safe.  Easy, we choose VSS.

Next, I need to browse for the srcSafe.ini.  Ok, no problem.  Except that when I try to browse the network or enter the path manually - the window tells me:

Windows cannot access \\networkshare\support
You do not have permission to access \\networkshare\support

Excuse me?  I've been using this for 10 years now.  And I can open explorer and get to the file just fine.  But yet this window won't let me choose OK to continue.

Thinking this was a one-time-glitch, I cancel the install and try again.  Same results again - no big surprise.

Annoyed and assuming it's "something with the installer and rights", I create a local source safe database and reinstall again - this time choosing the local path.  This was accepted by the installer and everything appeared to install correctly - except of course I'm not pointing the DSCCS.exe service to the correct location.

No problem, easily fixed, I think.  Until I ran into a second issue.

In Windows 7, I eventually figure out how to find the Dexterity SCCS applet and then launch it.  I shouldn't have any "rights" issues this time because I'm admin on the local machine where the service is running and have "Full Control" rights on the path the service points to.  The same Dexterity Source Code Control Server window opens up the same window that the installer uses.

But there is a difference this time- the Provider drop down list is empty.  So without being able to select Microsoft Visual SourceSafe, I cannot enter the path to the srcSafe.ini file.

Good grief - now what?

Looking in the registry under the 64 bit key, both Generic and Microsoft Visual SourceSafe keys are listed and the ProviderName is correctly set to Microsoft Visual Source Safe.

The 64 bit key is:

HKLM\Software\Wow6432Node\Great Plains Software\Dexterity Source Code Control Server\DSCCSProvider

The 32 bit key equivalent is: 

HKLM\Software\Great Plains Software\Dexterity Source Code Control Server\DSCCSProvider

At this point, I just want to get this working so I look in the registry sub key:

DSCCSProvider\Microsoft Visual SourceSafe

and find the ProviderProjectFile value. 

It is still set to my local VSS database.  I edit the value manually and set it to the network share path and save the setting to the new value:


After restarting the Microsoft Dexterity SCCS service to pick up the new path to the srcsafe.ini file, I test Dexterity and verify that Dexterity can correctly see the projects at that location.  It can.

So everything is working correctly once it is installed, it just takes a while to get there.

Now that I have everything working, I'm curious why exactly we have the issues in both the installer and the applet and if they are related.

So to test this out, I uninstall DSCCS.  I know, a glutton for punishment but since I know how work around these issues it really is a 5 minute install to fix things again with the workarounds.

After the uninstall is finished, I run the DSCCS installer again and after entering the path to the srcsafe.ini, I run Process Monitor to track pressing the OK button.  The installer returns the same error again and I stop Process Monitor.

Searching for the path I entered, I find it in the profile.  And not surprisingly, the error message returned by trying to get to that network share is ACCESS_DENIED.  At least the error was exactly what the installer told me.  That tells me that whatever permissions the installer is trying to use isn't sufficient to get to that network share - strange since I do have the necessary rights to that location.

Selecting the local VSS database again, I finish the install.

I turn on the Process Monitor again and run the Dexterity SCCS applet from the Windows Control Panel.  When the window opens again, I turn off Process Monitor.

Looking through the log, I find what I'm looking for.

The applet is attempting to read the registry key (on my 64 bit machine)

HKLM\Software\Wow6432Node\Great Plains Software\Dexterity Source Code Control Server\DSCCSProvider

It is trying to open the key with the "ALL_ACCESS" flag (so that it can read/write to the key) and this is failing with ACCESS_DENIED.  Since the applet couldn't enumerate the keys, the list doesn't get filled.

Knowing this was the issue, I did come up with two separate workarounds.

The easiest was to simply give myself explicit rights to the key.

Using regedit.exe, I found the registry key above.  I checked the permissions on the key and Administrators (which I am) did have full permissions to the key.  But knowing that Windows 7 doesn't run applications as "Administrator" unless you choose to do so, it is running as me which didn't have those permissions.

Easily fixed.  I added Full Control permissions to the "Authenticated Users" of this machine to the key.  After launching the Dexterity SCCS applet again, this time the list was filled and I was able to choose my srcsafe.ini on the network without issues.

As I did that, the thought of "running as administrator" came to mind.  Why not just run the applet from control panel using right click - run as administrator?  But another good idea spoiled by reality - that option doesn't exist from the control panel.

How about executing the applet from explorer?  Bingo.  After removing the permissions for "Authenticated Users" that I just added and locating the dsccs.cpl in my Windows\SysWOW64 folder (Windows\System32 folder on 32 bit), I chose to right click - Run as Administrator.  Again the applet opened up with the providers filled from the registry key.

So that workaround worked for me as well.

I'll leave you with a few parting thoughts.

  1. The names of the Providers that the Dexterity Source Control Server uses is taken from the keys in the DSCCSProvider key.  So if you wanted to have a provider called "My New Provider", you'd make a new key here and use the same settings that the VSS provider offers.
  2. In your new provider, by setting the InterfaceLibrary property to your own dll, in theory you could make your own custom source code control provider.  DSCCS will call the methods in that dll passing it "stuff" when Dexterity does the check out, check in, etc operations.  What "stuff" and what do these methods have to be named since Dexterity would call them with specific names?  Good questions with no answers as this is all undocumented. 
  3. You shouldn't have to install the 2010 DSCCS service if you don't want to.  I installed that version since this was a new machine and I was installing the 2010 version of everything all at once.  On my daily working machine, I used Dexterity 11.0.218 Dexterity with the 10.0.317 (comes with Dexterity 10.0.320) DSCCS service to successfully check in the RESM sample dictionary code to VSS.  No issues at all.  So if you have a machine set up already and you are just going to add Dexterity 2010 to the machine, I don't see any reason to change your DSCCS service since the new version doesn't provide any new features, benefits, or bug fixes.
  4. I tested the DSCCS applet on a Windows 2008 machine (not R2) and didn't have any issues.  Never tried on a Vista machine and so not sure if we'd see the same issue on that OS.
  5. This isn't a 64 bit issue, I could repro this on a Windows 7 32 bit machine as well.
  6. The applet bug is scheduled to be fixed in a service pack.
  7. The install bug isn't scheduled as of yet.

Dev Support