Create DotNetNuke Container

Create DotNetNuke Container

In Create DotNetNuke Skin we saw how to create DotNetNuke Skin and now we will see how to add new containers

Containers are the part of the skin where we define the way we want the modules we put in our portal to look. Containers can be very simple but they can also be very complicated... it's up to our taste and skills. The example below is a simple container.

Let's create two new files.

Our "MyFirstSkin/containers/common.ascx" file:

 <%@ Control language="vb" CodeBehind="~/admin/Containers/container.vb" AutoEventWireup="false" Explicit="True" Inherits="DotNetNuke.UI.Containers.Container" %>    
<%@ Register TagPrefix="dnn" TagName="ACTIONS" Src="~/Admin/Containers/SolPartActions.ascx" %>    
<%@ Register TagPrefix="dnn" TagName="TITLE" Src="~/Admin/Containers/Title.ascx" %>    
<%@ Register TagPrefix="dnn" TagName="ACTIONBUTTON1" Src="~/Admin/Containers/ActionButton.ascx" %>    
<%@ Register TagPrefix="dnn" TagName="ACTIONBUTTON2" Src="~/Admin/Containers/ActionButton.ascx" %>    
  
<table width="100%" border="0" cellspacing="0" cellpadding="0" class="ccommon">    
    <tr>    
        <td class="ctitle"><dnn:TITLE runat="server" id="dnnTITLE" /></td>    
    </tr>    
    <tr valign="top">    
        <td runat="server" id="ContentPane" class="ccontent"><dnn:ACTIONS runat="server" id="dnnACTIONS" /></td>    
    </tr>    
    <tr>    
        <td class="actionbuttons">    
                 
            <dnn:ACTIONBUTTON1 runat="server" id="dnnACTIONBUTTON1" CommandName="SyndicateModule.Action" DisplayLink="False" DisplayIcon="True" />    
            <dnn:ACTIONBUTTON2 runat="server" id="dnnACTIONBUTTON2" CommandName="PrintModule.Action" DisplayLink="False" DisplayIcon="True" />    
        </td>    
    </tr>    
</table> 

Our "MyFirstSkin/containers/container.css" file:

.ccommon{margin-bottom:20px;}    
.ccommon .ccontent{padding:10px 0;}    
.ccommon p{margin-top:0;}    
.ccommon .actionbuttons{text-align:right;font-size:1px;line-height:1px;height:1px;padding-right:20px;}    
.actionbuttons img{margin:0 0 10px 0;}  

Ready to upload it?

In order to make our skin available to our portal, we have to upload it using the admin interface (advanced user may also use FTP to upload the skin files).
Let's browse the "MyFirstSkin/containers/" folder and compress the common.ascx and container.css in in a MyFirstSkin.zip file.

It's time to run our browser and type in the address bar our DotNetNuke's portal URL, login and apply the skin!

Create DotNetNuke Skin

Create DotNetNuke Skin

Skins and modules are the reasons that DotNetNuke became so popular. They just get you involved. From the early versions you could skin it working with one HTML and one CSS file when for the most of the modern web applications out there, you have to deal with a bunch of files (sometimes and images!) to make them look the way you want.

With this tutorial I'll try to make you understand the basics about DotNetNuke skins and hopefully you'll learn how to create your own first skin from a static HTML page.

1) Skin folders

On your desktop, or wherever you want, create a new folder with the name "MyFirstSkin", that's the name of the skin we'll develop. In that folder create another one with the name "skins"

2) The skin.ascx from a static HTML page

First thing we have to do is to decide the way we want our pages to look like. Create a new HTML page so we can define what goes where.
As you can see all I did was to define the areas where later we'll put the dynamic content. We save this file as "skin.ascx" in the "MyFirstSkin/skins/" folder.

3) The skin.css and our skin.ascx page clean up

For the skin we need only everything in the "body" tag and the CSS styles we have included in the head area. So we "Cut" the styles inside the "style" tag and we "Paste" them in a new CSS file with the name "skin.css". We save this file in the same "MyFirstSkin/skins/" folder. Now we can remove the unneeded tags from the skin.ascx page... we keep only everything in the "body" tag.

In our skin.ascx file:

In our skin.css file:

4) DotNetNuke skin objects and the dreamweaver extension

Skin objects are special tags that DotNetNuke recognizes as dynamic content placeholders. So when we write this tag: <dnn:LOGO runat="server" id="dnnLOGO" /> we tell DotNetNuke to put our portal's logo in that place. Dynamic means that we'll be able to change the logo image from our portal's "Site Settings" without touch the code again. Let's put the skin objects in the areas we have specified, using the dreamweaver extension.

5. Ready to upload it?

In order to make our skin available to our portal, we have to upload it using the admin interface (advanced user may also use FTP to upload the skin files). Let's browse the "MyFirstSkin/skins/" folder and compress the skin.ascx and the skin.css in a MyFirstSkin.zip file.

It's time to run our browser and type in the address bar our DotNetNuke's portal URL, login and apply the skin!

Skins and Containers in DotNetNuke

Skins and Containers in DotNetNuke

Before starting with DotNetNuke we need to understand DotNetNuke structure.

A skin can be applied at host, portal, page or module level.

For each page within your portal you can set a different skin using the Page Settings.
For each module within a page you can specify a container to surround the module using the Module Settings.

Blue – Skin

Red – Containers

Green – Modules

DotNetNuke

DotNetNuke

Open Source Framework ideal for creating Enterprise Web Applications

I'm working on a project with friends and for this project we needed a Free Web Application Framework that will support Forums, Blogs, Shopping Cart, BackOffice and the most important is a Framework that can be modified easily and quickly.

DotNetNuke is one of the Top Web Application Framework on the market and it's Free.

 

If you are in the Web Business I recommend reading about DotNetNuke!

 

  Web Application Framework

DotNetNuke is an open-source Web Application Framework ideal for creating and deploying projects such as commercial websites, corporate intranets and extranets, online publishing portals, and custom vertical applications. 

DotNetNuke is provided as open-source software, licensed under a BSD agreement.  In general, this license grants the general public permission to obtain the software free-of-charge.  It also allows individuals to do whatever they wish with the application framework, both commercially and non-commercially, with the simple requirement of giving credit back to the DotNetNuke project community.

DotNetNuke is built on a Microsoft ASP.NET (VB.NET) platform, and is easily installed and hosted.  With a growing community of over 440,000 users, and a dedicated base of programming professionals, support for DotNetNuke is always close at hand.

Here you can watch a Online Demo

Load Agent and Load Controller Configuration Guide

Load Agent and Load Controller Configuration Guide

Published On: Ed Glas's blog

The Team Test Rig enables Team System users to run tests on one or more remote computers. A rig is made up of a single test controller and one or more test agents. The test controller can be installed on either one or two computers, and like Team Foundation Server, has both application and data tiers. A single test controller is used to coordinate the execution of multiple test agents running tests on multiple computers.

Supported Operating Systems

Hardware Requirements

For the test agent, memory and CPU typically control how much load can be generated. The test controller does not generate load, but does collect load test statistics from the agents and performance counter data from the agents and system under test. Therefore, database used by the controller requires considerable resources both for the amount of data stored and the number of agents involved in the load test scenario. Use the following table as a guide for determining hardware requirements for the controller and agent:

By default, SQL Express is installed with the controller and is used as the default store for load test results. Therefore, the controller runs an instance of SQL Express. For more information, see “SQL Sizing Considerations” later in this document.

Supported Configurations

Visual Studio, the Test Controller, SQL, and the Test Agent can all reside on the same computer or be installed on different computers. Typical computer configurations are:

Recommended Configuration:

• Computer 1: Visual Studio
• Computer 2: Controller, SQL Express
• Computer 3-n: Agents

Note   Installing an agent on the same computer as the controller can interfere with results collection. If you choose to do this, use the Agent Weighting property to reduce the amount of load generated by the agent installed on the same computer as the controller.

It is recommended that you install the agents on their own computer. Anything that is processing at the same time the agent is running affects the accuracy of the test. Agent weighting reduces the impact, but inaccuracies are still introduced.

The following additional configurations are available. They are listed in order of recommendation.

Alternative Configuration 1

• Computer 1: Visual Studio, Controller, SQL Express
• Computer 2-n: Agents

Alternative Configuration 2

• Computer 1: Visual Studio
• Computer 2: Controller, Agent
• Computer 3: SQL Express
• Computer 4-n: Agents

Alternative Configuration 3

• Computer 1: Visual Studio
• Computer 2: Controller, SQL Express, Agent
• Computer 3-n: Agents

Performance Considerations

Here are some additional considerations to consider when sizing the hardware:

The amount of load that a specific load agent can generate varies widely from test to test. Most tests are bound by the CPU. CPU use is directly proportional to requests per second (RPS). For other load tests, memory is the limiting factor. The RPS you can expect to drive from a load agent depends upon many factors. These include the following:

• User load
• Think time
• Authentication scheme
• Size of requests and responses
• Response time
• Level of response validation
• Test Type under load (either Web Test or Unit Test)

Think time is the primary factor for determining the number of users on a CPU-bound test. Changing think times from 2 seconds to 10 seconds allows you simulate 5 times more users, but the RPS being generated will be the same. If your goal is to simulate real users, set the think time to a value that reflects how you believe users will behave on your Web site. Increasing think time and the number virtual users will not necessarily place additional stress on your Web application.

Agents can be bound by memory on tests that use the Connection Per User connection mode. Two connection modes can be configured in the load test run settings. In Connection Pool mode (the default), connections are pooled, but each user still uses two connections when active. In this mode, all virtual users are multiplexed over the connection pool. This allows you to have 1000 active virtual users sharing 100 connections. In Connection Per User mode, each user has a connection that consists of two actual connections open to the server.

If load testing against a typical ASP.NET application with 3 to 5 second think time using Web tests, you can simulate around 1000 users from a single-processor load test agent with a 2 GHz CPU and 1 GB RAM (recommended configuration). The number of users supported is a function of the think time. With longer think times, more users can be supported.

SQL Sizing Considerations

By default, SQL Express is installed on the controller and is used by the controller as the default SQL store for load test results. The SQL Express database is license-limited to store 10 GB of data, which is around 24 hours of load test data for a typical load test. The space that is required for load test data varies greatly depending on the test.

During a load test, samples are collected for each counter instance on each computer. Therefore, the amount of space that is required in the database depends on the following factors: the number of counters collected, the number of computers involved in the test, and the number of samples taken, as controlled by the sample rate.

If appropriate, consider using a separate database to store the load test data. The database can be stored on either the controller computer or on a different computer. To change the data store, submit the SQL commands contained in the .sql file to the SQL server instance you want to use for the load test results store. These are two ways to do this. One way is to use the command sqlcmd from a command prompt and specify the options needed to connect to the desired database. Use the –i option to specify the path to loadtestresultsrepository.sql. Another way is to use one of the GUI interfaces to SQL, such as query analyzer, and open the .sql file and submit the connects.

Test Rig Software Requirements

Setup installs the following required components:

Test Rig User Accounts

The following types of accounts exist in the rig. Before installing, create the required accounts on the rig computers.

Requirements for Workgroups

If the computers in a rig are running in Work Group mode, that is, they are not in a domain, or they are running in different non-trusted domains, create local computer accounts on the controller. The accounts should have a matching password for each user who will access the controller, including the Agent service users.

For example, you have three computers, Controller1, Agent1, and Agent2. You must create local computer accounts on each computer for the agent service user and controller user. You also must make sure an administrator account exists on all three computers with the same username and password.

Note: If you are running on Windows XP in a work group, you must turn off Simple File Sharing. See this KB for info on how to do that: http://support.microsoft.com/kb/307874

Open Windows Explorer, choose Tools, and then choose Folder Options, Next, select the View tab, and turn off the "Use Simple File Sharing (Recommended)" option.

Next : Load Agent and Load Controller Installation Guide

Load Agent and Load Controller Installation Guide

Load Agent and Load Controller Installation Guide

Published On:Ed Glas's blog

Team Test Load Controller Installation

Warning   Set up the Controller before setting up any agents.

Note   Load controllers cannot be installed on domain controllers.

1. Start setup.exe located in the vs\controller folder.

The Welcome to Setup page appears.

2. Click Next.

The End-User License Agreement and Product Key page appears.

3. Review the End-User License Agreement (EULA) and select I accept the terms of the license agreement, if appropriate.

4. Enter the product key information and then click Next.

The Destination Folder page appears.

5. Click Browse to select a different destination folder, or click Next to use the default folder.

The Service Account page appears.

6. Enter the account name and password for the controller service account and then click Next.

The Ready to Install page appears.

7. Review the installation information and then click Install to continue.

The Installing Components page appears.

8. Upon successful installation, the Setup Completed Successfully page appears. Click Finish to complete the Setup program.

During Setup, you are prompted for the controller service account. The controller service account collects performance counters on other computers during a load test. Use a domain account that can easily be granted access to many computers. Grant the controller user rights to monitor performance on all the systems under test for the built-in performance monitoring capabilities to work.

Setup creates three local groups:

· TeamTestControllerAdmins

· TeamTestControllerUsers

· TeamTestAgentService

Add users who run tests to TeamTestControllerUsers. Add users who administer the test rig to TeamTestControllerAdmins. Agent setup automatically adds the users who Agent Services run as to TeamTestAgentService.

Note The user running the controller setup must be a member of local Administrators group.

The controller runs as a Windows Service on the computers on which it is installed. To view the properties of the service use Control Panel. In Control Panel, choose Administrative Tools and then choose Services. The name of the controller service is the Visual Studio Team Test Controller. The controller services can be started and stopped like other services in Windows.

The controller and agents can be configured and monitored by using the Administer Test Controller dialog box, available on the Test menu. For more information, see “How to: Administer the Rig” in the product documentation.

By default, the controller uses SQL Express to store load test results. SQL Express is license limited to store 4GB of data, which is approximately 10 hours of load test data. If you choose to use another SQL database to store the results, you can set up the Load Test Results Store after you have installed the controller. For more information, see “How to: Configure a Results Store using SQL” in the product documentation.

After you have configured your Load Test Results Store, you must indicate to the controller where the results are to be stored. For more information, see “How to: Select a Load Test Results Store” in the product documentation.

Load Controller Firewall Exceptions

If you are running Windows Firewall, the controller setup adds the following exceptions to your firewall:

If you are running on Windows XP in a work group, you must turn off Simple File Sharing. See this KB for info on how to do that: http://support.microsoft.com/kb/307874

Accessing the Controller

After the controller is installed, access to the controller is limited to members of the TeamTestControllerUsers and TeamTestControllerAdmins groups that were created during Setup, and to the Administrators group.
Add appropriate users and/or groups to these groups to allow them to access the controller.
Members of the TeamTestControllerAdmins group or the Administrators group can administer the controller by clicking the Test menu, and then choosing Administer Test Controller in Visual Studio.
Members of the TeamTestControllerAdmins group must also be power users or administrators on the controller computer.

Team Test Load Agent Installation

Warning    Set up the Controller before setting up any agents.

1. Start setup.exe located in the vs\agent folder.

The Welcome to Setup page appears.

2. Click Next.

The End-User License Agreement and Product Key page appears.

3. Review the End-User License Agreement (EULA) and accept the terms of the license agreement, if appropriate.

4. Enter the product key information and then click Next.

The Destination Folder page appears.

5. Click Browse to select a different destination folder, or click Next to use the default folder.

Note   If you are installing the Agent on the same computer as the Controller, the option to choose a new location is disabled.

The Specify Controller page appears.

6. Enter the computer name of the Team Test Load Controller computer and click Next.

Note   You can locate the name of the controller computer by clicking My Computer, right-clicking, choosing Properties and viewing the Computer Name tab.

The Ready to Install page appears.

7. Review the installation information and then click Install to continue.

The Installing Components page appears.

8. Upon successful installation, the Setup Completed Successfully page appears. Click Finish to complete the setup.

Following this, you will be prompted to restart your computer to complete the installation.

Note The user running the agent setup must be a member of local Administrators group and a member of the controller’s Administrators group.

During setup, you are prompted for the name of the controller computer that this agent will be associated with. Agent setup communicates with the controller to add the agent to the controller.

During setup, you are prompted for the Agent user. This user is automatically added to TeamTestAgentService group on the controller. Only Agent Service Users who are a member of this group are allowed to communicate with the controller.

The Agent service is named Visual Studio Team Test Agent. To view the properties of the service use Control Panel. In Control Panel, choose Administrative Tools and then choose Services. The agent services can be started and stopped like other services in Windows. Also the agents can be administered using the Administer Test Controller dialog box, available on the Test menu. For more information, see “How to: Administer the Rig” in the product documentation.

Note   AgentConfigUtil.exe is a command line utility that can be used to assign an Agent to a different Controller, or to add an Agent to a Controller if Agent setup fails to do so.

Load Agent Firewall Exceptions

If you are running Windows Firewall, Agent setup added the following exceptions to your firewall:

If you are running on Windows XP in a work group, you will also need to turn off Simple File Sharing.

Troubleshooting

Note   To verify the installation, run Visual Studio and launch the Administer Test Controller dialog box (available from the Test menu), connect to the controller, and check the status of the agents.
Agents should be in the Ready state.
If an agent is not in the list of agents, reinstall the agent or run AgentConfigUtil.exe after verifying that the controller is installed correctly.
If the agent is in the Disconnected state, check that the agent service user account has been added to the TeamTestAgentService user group on the controller. Also check the <installdir>\Microsoft Visual Studio 2005 Team Test Load Agent\LoadTest\agentConfigUtilSetup*.log file for errors.

“Rig failed to restart for controller <controller computer name>. The following error was reported Cannot open VSTTController service on computer <controller computer name>.”

This error occurs when a user tries to restart the rig from the Administer Test Controller dialog box, but while this user has been added to the TeamTestControllerAdmins group, they have not also been added to the Power User or Administrator group.

Web/Load Plugins And Rules Templates For Team System

Web/Load Plugins And Rules Templates For Team System

You can download the templates from here : www.codeplex.com/TeamTestPlugins

If you install these on your machine it makes creating new plugins much easier:

If you work with web and load tests you'll find these very handy, and they are xcopy-installed on your machine (you'll have them working in less than 5 minutes).

WCF Load Tests

WCF Load Tests

Rob Jarratt has published the WCF recording tool he has been working on to CodePlex at http://www.codeplex.com/wcfloadtest.

Project Description

This tool takes a WCF trace file and a WCF client proxy, or a WCF interface contract, and generates a unit test that replays the same sequence of calls found in the trace file. The code generated is easily modifiable so that data variation can be introduced for the purpose of doing performance testing.
The tool generates code for both Visual Studio 2005 and Visual Studio 2008. It also installs a wizard into both editions of Visual Studio for creating the trace and processing it from inside Visual Studio. If both editions are present the tool is installed into both editions. The source code is a Visual Studio 2005 project.

Features

The tool has the following main features:

• Replay of captured scenario in a unit test that can be included in a load test.
• Support for the DataContractSerializer.
• Support for message contracts.
• Support for proxies generated using svcutil.
• Support for clients that create proxies at run time from contract interfaces.
• Supports calls to multiple services in a single scenario.
• Supports multiple calls to the same service operation.
• Filtering by SOAP action of which messages in the trace to replay.
• Readable and modifiable code is generated.
• Automatic association of trace message with proxy method (requires all operations to have a unique SOAP action).
• Support for client and server side traces.
• A command line tool for processing traces and generating code.
• Visual Studio 2005/2008 integration (Team Developer, Team Test, Team Suite and for 2008 also Professional)) that can be used instead of the command line tool.

This is a really cool tool that will convert a WCF log file into a unit test that will replay the log. It came out of a load test engagement the services test labs did with a customer, so it is a proven solution.

If you are doing load testing on WCF, this tool provides a way to essentially record and playback the WCF traffic from an application.

Simulate Modal Windows Inside WPF Window Using Anonymous Methods

Simulate Modal Windows Inside WPF Window Using Anonymous Methods

You can read the original post in Mitsu's Blog

Introduction

In our windows applications we are commonly using modal windows. Let's remind the idea. Using windows forms, once a window is created, we can choose to show it in a modal manner (form.ShowDialog()). The window then becomes THE front window between all the other windows of our application. Moreover, all the other windows seem to be disabled. To be exact, the other windows are not responding to any input event anymore (keyboard, mouse, etc), but the are still able to respond to other events like paint.
The user must close the modal window by validating or canceling to come back to the previous state. You can repeat this model and then have a stack of modal windows.

This mechanism also exists using Windows Presentation Foundation. Let's remind that WPF windows are "real" windows even if they are hosting a DirectX surface.

Therefore, WPF brings a bunch of new functionalities that are mainly taking advantage of the control tree (events, datacontext, datatemplates, styles, resources, commandbindings, etc). So it's quite interesting to stay in the same window having an unique control tree.

Moreover, the natural vectorial capabilities of WPF let us imagine a complete nested world inside a single window, recreating a workspace with its own internal windows logic, like we know in games interfaces.

Obviously, you cannot define a child control as being modal. In this article, I will try to offer a solution to simulate this behavior.

How to block controls ?

The first step is to disable all the child controls of a same container, excepted the front one.

Disabling the input interaction will be easily done using:

control.IsEnabled = false; 

Let's imagine a method that would add a UserControl on the top of a child control collection of a Grid control, disabling existing children:

To "close" the UserControl as we could close a modal window, re-enabling the previous child control we could write:

void GoBackward() 
{
    modalGrid.Children.RemoveAt(modalGrid.Children.Count - 1);
    UIElement element = modalGrid.Children[modalGrid.Children.Count - 1];
    element.IsEnabled = true;
} 

This part is done. Those two methods allow to simulate a stack of graphic controls with a modal behavior. This solution supports pushing multiple controls.

That was the easy part. The next step is more complex.

How to block the calling code ?

Using Windows Forms, calling form.ShowDialog() is blocking.

This means that the following instructions will only be executed when the modal windows will close and return its modal value.

if (f.ShowDialog() == DialogResult.Ok)
{
    //Action OK
}
else
{
    //Action not OK
} 

The following actions will only be executed when the modal window is closed, creating a sequential execution, simple and comfortable for the developer.

Creating such a behavior in a single window using WPF is really too complex, almost impossible. Though we will try to simulate it.

We want to run an action at the moment when the modal control is closed. We will use a delegate to represent this action. This delegate will be invoked by the one that is closing the modal control. We will offer him a boolean to represent the modal result.

public delegate void BackNavigationEventHandler(bool dialogReturn);

Thanks to anonymous methods, we will keep a very comparable syntax that we had with windows forms:

NavigateTo(new UserControl1(), delegate(bool returnValue) {
    if (returnValue)
        MessageBox.Show("Return value == true");
    else
        MessageBox.Show("Return value == false");
}); 

The NavigateTo() method now accepts a second parameter we will have to store somewhere to call it later when closing the control.

As this method will have to support successive calls, an unique value will not be enough to store this delegate. We will use a stack to keep all these delegates:

private Stack<BackNavigationEventHandler> _backFunctions
    = new Stack<BackNavigationEventHandler>(); 

The NavigateTo() implementation becomes:

void NavigateTo(UserControl uc, BackNavigationEventHandler backFromDialog)
{
    foreach (UIElement item in modalGrid.Children)
        item.IsEnabled = false;
    modalGrid.Children.Add(uc);
    _backFunctions.Push(backFromDialog);
} 

We now need to get the delegate back from the stack (Pop) when calling GoBackward().

void GoBackward(bool dialogReturnValue)
{
    modalGrid.Children.RemoveAt(modalGrid.Children.Count - 1);
    UIElement element = modalGrid.Children[modalGrid.Children.Count - 1];
    element.IsEnabled = true;

    BackNavigationEventHandler handler = _backFunctions.Pop();
    if (handler != null)
        handler(dialogReturnValue);
} 

The one that is closing the control just need to call GoBackward(true); or GoBackward(false);

Make the access global

Last step, it would be useful to provide a global access to these two methods across the application. Doing such, any UserControl could easily call NavigateTo() to push a control and GoBackward() to close it, without knowing the modal context.

Let's group these functionnalities into an interface:

public interface IModalService
{
    void NavigateTo(UserControl uc, BackNavigationEventHandler backFromDialog);
    void GoBackward(bool dialogReturnValue);
} 

In our sample, we will simply implement this interface in our main window "Window1". It's quite a natural choice since "modalGrid" is contained in Window1.

A public static scope will provide a global access to the interface:

public class GlobalServices
{
    public static IModalService ModalService
    { 
        get
        {
            return (IModalService) Application.Current.MainWindow;
        } 
    } 
} 

Here we are !

We can now call anywhere in our code:

GlobalServices.ModalService.NavigateTo(new UserControl1(), delegate(bool returnValue) 
{ 
    if (returnValue) 
        MessageBox.Show("Return value == true"); 
    else 
        MessageBox.Show("Return value == false"); 
}); 

and 

GlobalServices.ModalService.GoBackward(true); 

Team System – How to Create Custom Extraction Rule [HE] - Screencast

Team System – How to Create Custom Extraction Rule [HE]

In this screen cast I will show how to create custom Extraction rules with Visual Studio 2008 / 2005.

Related Screencasts:
1 - Team System – How to Create Web Test\Coded Web Test - Screencast [HE]
2 - Team System – How to Create Data Binding Web Test - Screencast [HE]

Enjoy!

Team System – How to Create Custom Validation Rule [HE] - Screencast

Team System – How to Create Custom Validation Rule

Download MyWebTestProject Demo – Custom Validation Rule

In this screen cast I will show how to create custom validation rules with Visual Studio 2008 / 2005.

Related Screencasts:
1 - Team System – How to Create Web Test\Coded Web Test - Screencast [HE]
2 - Team System – How to Create Data Binding Web Test - Screencast [HE]

Enjoy!

Team System – How to add Validation and Extraction Rules to a Web Test - Screencast [HE]

Team System – How to add Validation and Extraction Rules to a Web Test

Download MyWebTestProject Demo – Validation Rules & Extraction Rules

In this screen cast I will show how to Validation Rules and Extraction Rules with Visual Studio Team Test 2008 / 2005.

1 - Team System – How to Create Web Test\Coded Web Test - Screencast [HE]
2 - Team System – How to Create Data Binding Web Test - Screencast [HE]

This is the last movie in this series

Enjoy!

Building solutions that reference to assemblies belonging to different team project

Building solutions that reference to assemblies belonging to different team project

If you facing the following

Scenario

Assume that we two projects (ConsoleApplication1 and ConsoleApplication2) under team project (TP1) and they are using the assembly (commonlibrary.dll) that is checked in under a different team project (TP2). Let us assume the corresponding paths under version control are Manish Agarwal published a great post about Building solutions that reference to assemblies belonging to different team project

How to display an assembly in the "Add Reference" dialog box

How to display an assembly in the "Add Reference" dialog box

When you are developing a class library, you may want Visual Studio .NET to list your library in the Add Reference dialog box on the .NET tab without the user having to browse for it.

This issue is not resolved if you install your assembly to the global assembly cache, because the Add Reference dialog box is path-based and does not enumerate the components from the global assembly cache.

To display your assembly in the Add Reference dialog box, you can add a registry key, such as the following, which points to the location of the assembly
[HKEY_CURRENT_USER\SOFTWARE\Microsoft\.NETFramework\AssemblyFolders\MyAssemblies]@="C:\\MyAssemblies"
where MyAssemblies is the name of the folder in which the assemblies reside.

*** You can create the this registry entry under the HKEY_LOCAL_MACHINE hive. This will change the setting for all of the users on the system. If you create this registry entry under HKEY_CURRENT_USER, this entry will affect the setting for only the current user.

Templex - The Team Foundation Server Process Template Library

Templex - The Team Foundation Server Process Template Library

Interested in sharing your process template? Would you rather use one someone else created? Check out the Templex project on CodePlex, which will serve as a library of process templates for use with Team Foundation Server.

Templex - The TFS Process Template Library