Wednesday, December 30, 2009

This issue occurs if all the following conditions are true:

  • You run the batch job on a Windows Server 2003-based member server.
  • The batch job runs as a non-interactive process.
  • The batch job is configured to run under the context of an account that is not a member of the Administrators group.
In Windows Server 2003, the Users group does not have Read and Execute permissions to the command processor (Cmd.exe). By default, the Cmd.exe program has the following permissions settings:
  • The Interactive implicit group and the Service implicit group have Read and Execute permissions.
    Note On a member server, the TelnetClients group also has Read and Execute permissions. On a domain controller, the Batch implicit group also has Read and Execute permissions.
  • The Administrators group and the System implicit group have Full Control permissions.
Method 1
Grant the Cmd.exe program Read and Execute permissions for the user account that the batch job runs under. To do this, follow these steps:
  1. Click Start, and then click Windows Explorer.
  2. Locate and then right-click the Cmd.exe file. The Cmd.exe file is located in the %windir%\System32 folder.
  3. Click Properties.
  4. Click the Security tab.
  5. Click Add.
  6. In the Enter the object names to select box, type the user name that the batch job runs under, and then click OK two times.
    Note When you add the user, the user is automatically granted Read and Execute permissions.
  7. Click Yes when you are prompted to continue.

Back to the top

Method 2
Grant Read and Execute permissions for the Cmd.exe file to the Batch group. This permits all batch processes to run the command processor. To do this, follow these steps:
  1. Click Start, and then click Windows Explorer.
  2. Locate and then right-click the Cmd.exe file. The Cmd.exe file is located in the %windir%\System32 folder.
  3. Click Properties.
  4. Click the Security tab.
  5. Click Add.
  6. In the Enter the object names to select box, type Batch, and then click OK two times.
  7. Click Yes when you are prompted to continue.

iisback /backup /e nosec /b autoback /overwrite

Tuesday, December 1, 2009

Method 1:

Create a registry entry for the file extension: HKEY_CLASSES_ROOT\.zzz\PersistentHandler\(Default) = {5e941d80-bf96-11cd-b579-08002b30bfeb}

Method 2:

Index all files:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\ContentIndex\FilterFilesWithUnknownExtensions = 1

Monday, August 24, 2009


Software Configuration Management (SCM) is a concept most developers have not had to deal with working individually or within smaller development groups. SCM is a pretty nebulous concept that is often defined in multiple ways, and distributed across various groups and processes differently; however each distinct aspect of SCM is related to other aspects of SCM. SCM typically tries to manage the following aspects:

  • Requirement/Defect/Feature Identification, Tracking and Reporting
  • Architecture, Design, Construction, and Debugging Components
  • Unit, Integration, System, Regression, User Acceptance, White Box and Black Box Testing
  • Packaging Components
  • Deploying Packages

These aspects are typically managed within the following processes:

  • Issue Management
  • Process Management
  • Release Management
  • Build Management
  • Quality Assurance
  • Configuration Management
  • Change Management

Within smaller groups, changes to dependant applications are often communicated verbally and dealt with as the changes come, however, with larger development groups, these changes can be harder to communicate to everyone affected. Therefore, a good understanding of Version Control and adherence to proper setup to enable continuous integration is a basic foundation to enabling multiple projects to succeed.


The scope of this document is to walk through project setup and referencing to help alleviate hurdles with source control management or change management as it relates to .NET applications.


It is assumed:

  1. A live TFS 2008 server and Build server is setup is available.
  2. Working knowledge of checking in and checking out from TFS.
  3. Working knowledge of branching and merging in TFS.
  4. Basic knowledge of C#

Next >>

For this walkthrough, we will setup two solutions. One is a shared library to simulate common code that is used by multiple projects. The other is an application that will utilize the shared library.

We will also setup branching and merging to control which applications use the shared library. Often, people will just make a reference to the shared library. Visual Studio will copy the output to the build folder and it will work. The problem arises when you have to update that shared library with 5, 10, or more applications, but you are not sure what code base is used by which version of the DLL.

One of the deficiencies of Visual Studio, is that it does not automatically update the version in the Assembly before the build.

<Intro> / << Prev / Next >>

  1. clip_image002Create a new class library project called Library1 within a solution called LabelLibrary. Be sure to create a directory for the solution.

  2. Add a second class library called Library2 to the solution. clip_image004

  3. clip_image006Add an additional class to Library1 called Class2. The class design for these examples does not matter, but add some code to compile.

  4. Build the release and debug configurations of the solution.

<Intro> / << Prev / Next >>


  1. Create a new console application project called App1 within a solution called App1. Be sure to create a directory for the solution.

  2. Add references to the debug versions of the DLLs from Library1 and Library2 of LabelLibrary. clip_image004
  3. Add some code to reference the classes created in the Libraries.
  4. Build and Check in.

<Intro> / << Prev / Next >>

  1. Create a Build Definition for each solution.
  2. Try to name it the same as the solution file.
  3. Select the source control folder of the solution.
    Sometimes the Build server complains that the mapping is already used. You need to log in to the build server as the build server username and password and reset the mappings in the Source Control Workspace.
  4. Be sure to set the retention policy to something reasonable.
  5. Setup a share for the successful builds to be copied to. This is where testing will get the files to do quality assuranceclip_image010
  6. Set build to build for each check in. This may or may not result in more builds.

<Intro> / << Prev / Next >>

  1. Show all files in the library projects and select Include in Project from the context menu for the Release folders under bin.
  2. Check in changes. Your source control explorer may look like the following:
  3. Create a folder under the application folder of App1 called Dependencies.
  4. Right click on each of the Release folders checked in and Branch.
  5. Select Label from the Branch from version drop down, and select the last build label.
  6. Browse for the Dependencies folder created earlier and type in the name of the original project. Ex: Library2
  7. Repeat for the other library project.
  8. Check in the branch operation.
  9. Open the application project, remove the references to the DLLs from the project folder of the libraries.
  10. Re-add the references to the DLLs in the Dependencies folder.
  11. Check in the project. The Build server should kick off and build the application successfully.

<Intro> / << Prev / Next >>

  1. Open the LabelLibrary solution and rename a class name. This is a sure fire way of making dependent applications breakclip_image002clip_image004
  2. Don’t forget to check out the Release folder since it was checked in last.
  3. Rebuild both Release and Debug and Check in.
  4. The Build server will automatically rebuild the application on the server and label your build of the shared library.clip_image014
    The build server is only verifying the code compiles, tests (not shown) are run and the result is copied to the folder specified in the build definition. Remember that the dependent projects are branched from your build in the project, not the build server’s build.
  5. Queue a build for the App1 solution to see if it still works. The build server didn’t rebuild this one since we didn’t check it out.
  6. It still works!
Let’s update the App1 project with the new version of the shared library.
  1. Select each folder that was branched earlier and select merge from the context menu.
  2. Notice that the target branch is already populated with the path for the earlier branch!
  3. Click Next and select Label.
  4. Click the elipses to find the last build of the shared library.
  5. Click close and finish.
  6. Check in the changes.
  7. The build server will automatically detect the changes and build the application.
  8. Obviously it failed because we renamed the class!
Lets’ Fix It
  1. Open the App1 solution and fix the references to the new class name.
  2. Check in! We should build it locally to verify that our changes work.
  3. The build server automatically notices changes and attempts rebuilding it.
  4. Success!!

    Now we can improve, enhance, refactor, and eliminate shared libraries independently of other dependent applications/

<Intro> / << Prev / Next >>

Now, every time we release an application, our debug version of our library is referenced in our released application!! If we use the release version, we can’t debug it easily. How can we setup our projects so it knows what to use?

<Intro> / << Prev / Next >>

You might think we can simply…

  1. Add the Debug folder or the Release folder as well to the project and check it in.
  2. Then re-branch the built DLL’s to the application solution.
  3. Check in…
  4. clip_image016Re-reference the debug and release versions in their respective configurations…

Even changing the default alias!! Doesn’t work…

<Intro> / << Prev / Next >>