Scheduled Jobs 0 comments

http://support.microsoft.com/kb/867466

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.

How To - Backup IIS Metabase 0 comments

iisback /backup /e nosec /b autoback /overwrite

http://support.microsoft.com/kb/302573

How To – Search All Files 0 comments

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

http://support.microsoft.com/kb/309173

Version Control and Continuous Integration 0 comments

Introduction

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.

Scope

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.

Assumptions

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 >>

The Projects 0 comments

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 >>

The Projects - Shared Library 0 comments

1. Create 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.

3. Add 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 >>

The Projects – Main Application 0 comments

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.
   
3. Add some code to reference the classes created in the Libraries.
   
4. Build and Check in.
   

<Intro> / << Prev / Next >>