clraddins Wiki & Documentation Rss Feed

New Comment on "samples"

koleraba — Tue, 28 Dec 2010 16:22:58 GMT

The "Event Sample" sample those not seem to work. I downloed the source, opened it in visual studio 2008 and try to compile it and I get a bounch of compile errors. I think the problem is that referenced PipelineHints file does not exist. Did andybody had a similiar problem?

New Comment on "Using the VS Add-In"

rogeclub — Sat, 05 Sep 2009 10:25:27 GMT

There appears to be an issue using VS2008 on Windows7. When generating the pipeline for the 1st time it calls each of the assemblies Template rather than say "AddInViews". This causes issues when building the AddInStore. To fix it make sure all the projects generate the assembly using the same name as the project generated by the tool.

New Comment on "Samples"

evgenyvinnik — Mon, 06 Jul 2009 11:51:41 GMT

This samples is a great help for those who are new in creating applications with add-ins just like me. Thought they a complicated a bit and have lack of comments and documentation.

Updated Wiki: Add-in FxCop Rules

mSid — Tue, 02 Dec 2008 21:53:02 GMT

Add-in FxCop Rules

One of the common requests we get is for a way to verify that Contract and View assemblies are built using the right practices with regard to isolation and version resilience. We have developed two sets of FxCop rules for this purpose:

The Add-in View FxCop rules run against view assemblies and ensure that a host's object model (view) can be easily adapted into a complete pipeline that uses the Add-in Framework.

The Add-in Contract FxCop rules ensure that contracts follow the contract isolation and version-resilience guidelines. This ensures that contracts built today will meet versioning needs when moving to a new version of the host.

You can download the latest release here: Add-in FxCop Rules - v1.0 beta

Updated Wiki: Home

mSid — Thu, 03 Jul 2008 19:20:17 GMT

Introduction
Welcome to the CodePlex site for the Managed Extensibility and Add-In Team. This site will be the home to both samples and tools designed to help you make the best use of the new System.AddIn features in the .Net FX v3.5. We'll continue to use our blog http://blogs.msdn.com/clraddins/ for information and discussion about our work, but from now on we'll be hosting our samples here for easier access.

The initial focus will be on two things:

Bringing over samples from the team blog to this site
The release of the Pipeline Builder tool

For more information on our work please see our additional resources page.

Project Description: Add-in FxCop Rules
One of the common requests we get is for a way to verify that Contract and View assemblies are built using the right practices with regard to isolation and version resilience. We have developed two sets of FxCop rules for this purpose. Head over to the project page to download them: Add-in FxCop Rules

Project Description: Pipeline Builder
This has been one of the most requested features we've had since people started learning more about our model and playing with the bits. For a particular version of an application writing the code for the views and adapters can be a lot of mechanical repetitious work and generally only gets interesting when you are writing "cross-version" adapters. So what we've done is build a tool that will automatically generate the source code for the views and adapters for a given contract assembly. This tool is really just a library that can be used from various other places and our release will include a simple command line tool as well as a VS 2008 add-in that will automatically generate the projects and set references/build paths for you appropriately. For more information on this tool as well as links and descriptions of our releases please visit its wiki page: Pipeline Builder.

Project Description: Samples
Up until now we've been posting our samples to our blog but that doesn’t scale well as we add more samples and update existing ones. To make it easier for us to post samples, and you to find them, we'll start using this site. Currently we’ve just ported over all the existing samples that we’ve published (on our blog and through articles) but soon we'll start posting some of the other internal samples we've built as well as responding to requests from the community.

Updated Wiki: Add-in FxCop Rules

mSid — Thu, 03 Jul 2008 19:18:33 GMT

One of the common requests we get is for a way to verify that Contract and View assemblies are built using the right practices with regard to isolation and version resilience. We have developed two sets of FxCop rules for this purpose:

The Add-in View FxCop rules run against view assemblies and ensure that a host's object model (view) can be easily adapted into a complete pipeline that uses the Add-in Framework.

The Add-in Contract FxCop rules ensure that contracts follow the contract isolation and version-resilience guidelines. This ensures that contracts built today will meet versioning needs when moving to a new version of the host.

You can download the latest release here: Add-in FxCop Rules - v1.0 beta

UPDATED WIKI: resources

JesseKaplan — Mon, 25 Feb 2008 18:42:01 GMT

Resources

MSDN Resources

Conceptual/How-to Documentation: http://msdn2.microsoft.com/en-us/library/bb384241.aspx
API Reference: http://msdn2.microsoft.com/en-us/library/system.addin.hosting.aspx

Online Articles

MSDN Magazine 02/2007 http://msdn.microsoft.com/msdnmag/issues/07/02/CLRInsideOut/default.aspx
MSDN Magazine 03/2007 http://msdn.microsoft.com/msdnmag/issues/07/03/CLRInsideOut/default.aspx

These articles provide an introduction to our work while walking you through the process of first building the host and add-in, and then building the cross-version adapters when you move to a V2 host

Microsoft Architecture Journal 12 (July 2007): http://msdn2.microsoft.com/en-us/arcjournal/bb735304.aspx

This article offers both an introduction to our APIs and architecture but also a discussion about how to use System.AddIn to build more reliable hosts

Blogs

System.AddIn Team Blog: http://blogs.msdn.com/clraddins/
Team Members Blogs

Jack Gudenkauf: http://blogs.msdn.com/jackg/
Thomas Quinn: http://blogs.msdn.com/tq/
Jason He: http://blogs.msdn.com/zifengh/

Videos

Screen Casts from Daniel Moth (MSFT UK Developer Evangelist)

UPDATED WIKI: resources

JesseKaplan — Mon, 25 Feb 2008 18:25:53 GMT

Resources

MSDN Resources

Conceptual/How-to Documentation: http://msdn2.microsoft.com/en-us/library/bb384241.aspx
API Reference: http://msdn2.microsoft.com/en-us/library/system.addin.hosting.aspx

Online Articles

MSDN Magazine 02/2007 http://msdn.microsoft.com/msdnmag/issues/07/02/CLRInsideOut/default.aspx
MSDN Magazine 03/2007 http://msdn.microsoft.com/msdnmag/issues/07/03/CLRInsideOut/default.aspx

These articles provide an introduction to our work while walking you through the process of first building the host and add-in, and then building the cross-version adapters when you move to a V2 host

Microsoft Architecture Journal 12 (July 2007): http://msdn2.microsoft.com/en-us/arcjournal/bb735304.aspx

This article offers both an introduction to our APIs and architecture but also a discussion about how to use System.AddIn to build more reliable hosts

Blogs

System.AddIn Team Blog: http://blogs.msdn.com/clraddins/
Team Members Blogs

Jack Gudenkauf: http://blogs.msdn.com/jackg/
Thomas Quinn: http://blogs.msdn.com/tq/
Jason He: http://blogs.msdn.com/zifengh/

Videos

Screen Casts from Danial Moth (MSFT UK Developer Evangelist)

UPDATED WIKI: New in Feb CTP

JesseKaplan — Sat, 09 Feb 2008 00:15:47 GMT

High level Changes

Major Changes:

Better VS Integration
Greatly improved performance of the VS add-in for larger contract assemblies
Better default naming conventions for views and adatpers
Support for structs in Contracts

Minor Breaking Changes:

Generated files are now placed in a "Generated Files" sub folder in the main project and with a ".g.cs" extension rather than ".generated.cs". You will need to delete the existing generated source files to compile.
NamespaceAttribute is no longer valid on assemblies
The namespaces for generated code has changed slightly, see Namespaces Should Follow Contract Namespace, NOT AssemblyName

Naming related changes

New heuristic for choosing namespaces used in generated code

If NamespaceAttribute specifies a namespace for the contract in the current segment (views, host view, add-in view, host side adapter, or add-in side adpater) then we will use that namespace
If the namespace for the contract ends in ".Contracts" the ".Contracts" will be removed and the remaining name will be used, as-is, in the view assemblies. A ".HostSideAdapters" or ".AddInSideAdapters" will be added to the name used in the view in this case.
If there is no namespace attribute and the namespace for the type does not end in .Contracts it will choose a namspace based on the assembly name of the contract.

Namespace attribute can no longer be applied to assemblies
Namespace attribute can now be applied to all types (IContracts, Enum contracts, Struct contracts)
Generated files now have a ".g.cs" extension rather than ".generated.cs"

VS Integration

Dramtically improved performance for contract assemblies that result in many generated source files
Fit and finish

Updates to the UI of various dialogs
Automatically collapse "References" tabs in generated projects
Automatically collapse the the generated source code folders for adapters
Status indicator for progress of generation
Better error messages across the board

Better support for custom code in generated projects

All generated code is moved into "Generated Files" sub-folders in projects
Only replace code that is located in the "Generated Files" sub-folders
Detect when developers have modified a generated file and prevent the tool from overriding these choices
Detect when generated projects exist, but are not part of solution, and warn developer rather than overriding them

Code Generation

Added support for struct contracts defined in contract assemblies
Support for passing arrays of struct and enum contracts
Better error checking in contract assembly
Different code generator options

Change of bracing style
No longer skip lines between members

Quick Samples:

Blank Pipeline Project (Updated to include a sample contract)
Common Pipeline Scenarios (Updated to include samples for structs)

UPDATED WIKI: New in Feb CTP

JesseKaplan — Sat, 09 Feb 2008 00:15:17 GMT

New in Feb CTP

Summary

Major Changes:

Better VS Integration
Greatly improved performance of the VS add-in for larger contract assemblies
Better default naming conventions for views and adatpers
Support for structs in Contracts

Minor Breaking Changes:

Generated files are now placed in a "Generated Files" sub folder in the main project and with a ".g.cs" extension rather than ".generated.cs". You will need to delete the existing generated source files to compile.
NamespaceAttribute is no longer valid on assemblies
The namespaces for generated code has changed slightly, see Namespaces Should Follow Contract Namespace, NOT AssemblyName

Naming related changes

New heuristic for choosing namespaces used in generated code

If NamespaceAttribute specifies a namespace for the contract in the current segment (views, host view, add-in view, host side adapter, or add-in side adpater) then we will use that namespace
If the namespace for the contract ends in ".Contracts" the ".Contracts" will be removed and the remaining name will be used, as-is, in the view assemblies. A ".HostSideAdapters" or ".AddInSideAdapters" will be added to the name used in the view in this case.
If there is no namespace attribute and the namespace for the type does not end in .Contracts it will choose a namspace based on the assembly name of the contract.

Namespace attribute can no longer be applied to assemblies
Namespace attribute can now be applied to all types (IContracts, Enum contracts, Struct contracts)
Generated files now have a ".g.cs" extension rather than ".generated.cs"

VS Integration

Dramtically improved performance for contract assemblies that result in many generated source files
Fit and finish

Updates to the UI of various dialogs
Automatically collapse "References" tabs in generated projects
Automatically collapse the the generated source code folders for adapters
Status indicator for progress of generation
Better error messages across the board

Better support for custom code in generated projects

All generated code is moved into "Generated Files" sub-folders in projects
Only replace code that is located in the "Generated Files" sub-folders
Detect when developers have modified a generated file and prevent the tool from overriding these choices
Detect when generated projects exist, but are not part of solution, and warn developer rather than overriding them

Code Generation

Added support for struct contracts defined in contract assemblies
Support for passing arrays of struct and enum contracts
Better error checking in contract assembly
Different code generator options

Change of bracing style
No longer skip lines between members

Quick Samples:

Blank Pipeline Project (Updated to include a sample contract)
Common Pipeline Scenarios (Updated to include samples for structs)

UPDATED WIKI: New in Feb CTP

JesseKaplan — Sat, 09 Feb 2008 00:14:35 GMT

Summary

Major Changes:

Better VS Integration
Greatly improved performance of the VS add-in for larger contract assemblies
Better default naming conventions for views and adatpers
Support for structs in Contracts

Minor Breaking Changes:

Generated files are now placed in a "Generated Files" sub folder in the main project and with a ".g.cs" extension rather than ".generated.cs". You will need to delete the existing generated source files to compile.
NamespaceAttribute is no longer valid on assemblies
The namespaces for generated code has changed slightly, see Namespaces Should Follow Contract Namespace, NOT AssemblyName

Naming related changes

New heuristic for choosing namespaces used in generated code

If NamespaceAttribute specifies a namespace for the contract in the current segment (views, host view, add-in view, host side adapter, or add-in side adpater) then we will use that namespace
If the namespace for the contract ends in ".Contracts" the ".Contracts" will be removed and the remaining name will be used, as-is, in the view assemblies. A ".HostSideAdapters" or ".AddInSideAdapters" will be added to the name used in the view in this case.
If there is no namespace attribute and the namespace for the type does not end in .Contracts it will choose a namspace based on the assembly name of the contract.

Namespace attribute can no longer be applied to assemblies
Namespace attribute can now be applied to all types (IContracts, Enum contracts, Struct contracts)
Generated files now have a ".g.cs" extension rather than ".generated.cs"

VS Integration

Dramtically improved performance for contract assemblies that result in many generated source files
Fit and finish

Updates to the UI of various dialogs
Automatically collapse "References" tabs in generated projects
Automatically collapse the the generated source code folders for adapters
Status indicator for progress of generation
Better error messages across the board

Better support for custom code in generated projects

All generated code is moved into "Generated Files" sub-folders in projects
Only replace code that is located in the "Generated Files" sub-folders
Detect when developers have modified a generated file and prevent the tool from overriding these choices
Detect when generated projects exist, but are not part of solution, and warn developer rather than overriding them

Code Generation

Added support for struct contracts defined in contract assemblies
Support for passing arrays of struct and enum contracts
Better error checking in contract assembly
Different code generator options

Change of bracing style
No longer skip lines between members

Quick Samples:

Blank Pipeline Project (Updated to include a sample contract)
Common Pipeline Scenarios (Updated to include samples for structs)

UPDATED WIKI: New in Feb CTP

JesseKaplan — Fri, 08 Feb 2008 22:54:40 GMT

Summary

Major Changes:

Better VS Integration
Greatly improved performance of the VS add-in for larger contract assemblies
Better default naming conventions for views and adatpers
Support for structs in Contracts

Minor Breaking Changes:

Generated files are now placed in a "Generated Files" sub folder in the main project and with a ".g.cs" extension rather than ".generated.cs". You will need to delete the existing generated source files to compile.
NamespaceAttribute is no longer valid on assemblies
The namespaces for generated code has changed slightly, see Namespaces Should Follow Contract Namespace, NOT AssemblyName

Naming related changes

New heuristic for choosing namespaces used in generated code

If NamespaceAttribute specifies a namespace for the contract in the current segment (views, host view, add-in view, host side adapter, or add-in side adpater) then we will use that namespace
If the namespace for the contract ends in ".Contracts" the ".Contracts" will be removed and the remaining name will be used, as-is, in the view assemblies. A ".HostSideAdapters" or ".AddInSideAdapters" will be added to the name used in the view in this case.
If there is no namespace attribute and the namespace for the type does not end in .Contracts it will choose a namspace based on the assembly name of the contract.

Namespace attribute can no longer be applied to assemblies
Namespace attribute can now be applied to all types (IContracts, Enum contracts, Struct contracts)
Generated files now have a ".g.cs" extension rather than ".generated.cs"

Quick Samples:

Blank Pipeline Project (Updated to include a sample contract)
Common Pipeline Scenarios (Updated to include samples for structs)

UPDATED WIKI: New in Feb CTP

JesseKaplan — Fri, 08 Feb 2008 22:54:30 GMT

Summary

Major Changes:

Better VS Integration
Greatly improved performance of the VS add-in for larger contract assemblies
Better default naming conventions for views and adatpers
Support for structs in Contracts

Minor Breaking Changes:

Generated files are now placed in a "Generated Files" sub folder in the main project and with a ".g.cs" extension rather than ".generated.cs". You will need to delete the existing generated source files to compile.
NamespaceAttribute is no longer valid on assemblies
The namespaces for generated code has changed slightly, see Namespaces Should Follow Contract Namespace, NOT AssemblyName

!!Naming related changes

New heuristic for choosing namespaces used in generated code

If NamespaceAttribute specifies a namespace for the contract in the current segment (views, host view, add-in view, host side adapter, or add-in side adpater) then we will use that namespace
If the namespace for the contract ends in ".Contracts" the ".Contracts" will be removed and the remaining name will be used, as-is, in the view assemblies. A ".HostSideAdapters" or ".AddInSideAdapters" will be added to the name used in the view in this case.
If there is no namespace attribute and the namespace for the type does not end in .Contracts it will choose a namspace based on the assembly name of the contract.

Namespace attribute can no longer be applied to assemblies
Namespace attribute can now be applied to all types (IContracts, Enum contracts, Struct contracts)
Generated files now have a ".g.cs" extension rather than ".generated.cs"

Quick Samples:

Blank Pipeline Project (Updated to include a sample contract)
Common Pipeline Scenarios (Updated to include samples for structs)

UPDATED WIKI: New in Feb CTP

JesseKaplan — Fri, 08 Feb 2008 22:27:28 GMT

Details to come.

Major Changes:

Better VS Integration
Greatly improved performance of the VS add-in for larger contract assemblies
Better default naming conventions for views and adatpers
Support for structs in Contracts

Minor Breaking Changes:

Generated files are now placed in a "Generated Files" sub folder in the main project and with a ".g.cs" extension rather than ".generated.cs". You will need to delete the existing generated source files to compile.
NamespaceAttribute is no longer valid on assemblies
The namespaces for generated code has changed slightly, see Namespaces Should Follow Contract Namespace, NOT AssemblyName

Quick Samples:

Blank Pipeline Project (Updated to include a sample contract)
Common Pipeline Scenarios (Updated to include samples for structs)

UPDATED WIKI: Pipeline Builder

JesseKaplan — Fri, 08 Feb 2008 22:19:33 GMT

Pipeline Builder Home Page

This has been one of the most requested features we've had since people started learning more about our model and playing with the bits. For a particular version of an application writing the code for the views and adapters can be a lot of mechanical repetitious work and generally only gets interesting when you are writing "cross-version" adapters. So what we've done is build a tool that will automatically generate the source code for the views and adapters for a given contract assembly. This tool is really just a library that can be used from various other places and our release will include a simple command line tool as well as a VS 2008 add-in that will automatically generate the projects and set references/build paths for you appropriately.

This tool should still be considered in pre-release state but because of the nature of it that shouldn't discourage you from using it in your products. While we are still working on adding additional features (and will be taking requests/suggestions for them), as long as tool has the features you need you should feel comfortable using it. Since the code this tool generates doesn't take any dependencies on the tool, or related assemblies, new updates will not impact your app and should be easy enough to incorporate in your build process. If we post updates that change the code generated for currently available features we'll make sure that gets noted and describe the changes.

Currently the tool only generates C# projects and source code but the code it generates can be consumed from any other .Net language. The contract assembly itself can also be built in any language.

Getting Started
This project consists of three major pieces:

PipelineBuilder assembly for examninig the contract assembly and generating the source code
PipelineHints assembly that contains custom attributes you can use in the contract's source code to customize the PipelineBuilder output
VSPipelineBuilder VS2008 add-in that integrates with VS and takes care of adding projects and source files to solutions

You can download our current CTP here: Pipeline Builder CTP Feb-2008

If you are only interesting in using this tool (and not worrying about modifying it) then you just need to read these sections:

If your interested in looking at and/or modifying the code of the pipeline builder itself you can find more information here: Pipeline Builder Development

For more information about this tool you can read our Pipeline Builder FAQ.

UPDATED WIKI: Using the VS Add-In

JesseKaplan — Wed, 30 Jan 2008 18:45:17 GMT

Using the VS Add-In

Installing the VS Add-In
This add-in only works with VS 2008. This add-in is still in an early stage of development as most of our work has been focused on the actual pipeline generation work rather than the VS integration. It should work well enough to help you get started and develop your pipeline but it isn't as flexible and robust as we would eventually like. In particular it requires a fairly specific solution structure (outlined below). Error reporting is limited to a dialog that gives you the ToString of any exception that is thrown.

You can download the current release here: Pipeline Builder CTP Jan-2008

The installation program will place files in the specfied directory and will install the necessary components into the GAC, but it will not register the add-in with VS.
To register the installed add-in with VS you need to:

Start VS
Click on the Tools->Options menu item
Select the Environment->Add-In/Macros Security item
Add the path where you installed this addin to the "Add-in File Paths" list (default is c:\Program Files\Microsoft\Visual Studio Pipeline Builder)
Restart VS

After you restart VS you should see a new item in your Tools menu list with a smiley icon and the name "PipelineBuilder"

Settuping up your Solution
The VS add-in works best when you have a fairly specific set-up in your solution. Your .sln file should be in one folder with each project in sub-folders (this is the default setting when creating a new project/sln in VS and you choose the "Create Directory For Solution" option). The output of your projects should be redirected to a single output folder that is a direct subfolder of the solution's folder. Additionally, the output for your contract project should be in a "Contracts" subfolder underneath your output folder. With this setup the host will go directly into "output" and it can use the PipelineStoreLocation.ApplicationBase enum for finding add-ins in that directory.

To redirect the output of a project you need to right-click on the project in "Solution Explorer" and hit properties. From there you click on the "Build" tab and towards the bottom of that path you can find the "Ouput Path" text box. For your Contracts project you would want a path like "..\output\Contracts", the corresponding host path would be "..\output\" and the add-ins (if built with the same solution) would have the path "..\output\AddIns\MyAddInName". The below screen show shows the output settings for a sample Contracts assembly project:

Visually the directory structure should look like this:

Solution Directory

Solution File
Contract Project Directory
Host Project Directory (optional)
Output directory (the name is up to you)

Contracts (your contract project should build here)

For your convenience we have a solution with an empty Contracts project set up according the above guidelines available here: Sample- Blank Pipeline Project
For more information on going from this blank project to a working contract solution please see this page

Running the PipelineBuilder Add-In
Once you've set your solution up, as described above, you can simply open it and use the tool. You can run the tool by clicking on the "PipelineBuilder" item under your tools menu in VS. It will pop up this dialog:

It will try and guess which project in your current solution is the "Contract" project and if it guesses incorrectly you can choose the correct one from the "Contract Source Project" drop down box. The default values for the "Project Location" and "Build Location" were determined by inspecting the "Contract Source Project" and should be correct if you followed the guidelines above.

Once you hit "Ok" it will examine the project output of your "Contract Source Project" (Important: this tool examines your binary and not the source code, if this project is not built the tool won't work) and will take care of the rest:

If the projects for the various pipeline segments are not part of your solution it will:

Create them in the in the directory specified

If the project being generated is not part of the solution but a directory with its name is located in the "Project Location" path then it will delete that directory

Set up the references appropriately
Set up their build paths appropriately
Add the generated source files to each project with a .generated.cs extension

If the projects for the various pipeline segments are part of your solution it will:

Reuse the existing projects
Delete all files with the .generated.cs extension
Add the generated source files to each project with a .generated.cs extension

Important: if you have modified any of the generated source files you should remove the .generated section from the file name to prevent the tool from deleting it. You should also mark it's class with the CustomPipelineAttribute to avoid have the tool re-generate the code you've decided to customize. For more information on this attribute see Using PipelineHints to Customize Output

After the tool is finished you should be able compile and everything should be set. If you are developing the host application concurrently simply add a reference from it to the appropriate view project and do the same for the add-ins. Remember to change properties of the add-ins reference to its view and set "CopyLocal=False". For the host the default value of "CopyLocal=True" is generally correct.

If, after running the tool a dialog pops up reporting the following exception then it means that it could not find your contract assembly and that you just need to rebuild that project.

System.Reflection.TargetInvocationException: Exception has been thrown 
by the target of an invocation. ---> System.IO.FileNotFoundException:

UPDATED WIKI: Samples

JesseKaplan — Fri, 25 Jan 2008 18:55:46 GMT

Samples

Updated Samples from our Blog and Articles

Pipeline Builder Tool Samples

New Samples

Event Sample

This sample includes an end-to-end solution (host, pipeline, addin) that demonstrates how hosts and add-ins can subscribe to each others events.
It also shows how you can use CancelableEvents, in this case to cancel work the add-in is reporting progress on.

UPDATED WIKI: From Blank Pipeline Project To Working Solution

JesseKaplan — Sat, 12 Jan 2008 00:09:33 GMT

Going from the Blank Contract Sample to a Working Solution

This page is designed to help walk you through all the steps needed to start using this samples as a starting point for your project: Sample- Blank Pipeline Project. We'll use a simple calculator contract as a sample.

When you open the solution you'll see the Contracts.cs file with these contents:

/// Copyright (c) Microsoft Corporation.  All rights reserved.
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.AddIn.Contract;
using PipelineHints;
 
 
//You should change the assembly name and default namespace for this project before you use it. 
namespace Sample.Blank.Contracts
{
   
}

The first thing you should do is update the assembly name and default namespace for this project. To do this right click on the project and click on properties. From there click on the "Application" tab. In this case we'll change both the "Default namespace" and the "Assembly name" to "Sample.Calculator.Contracts". You can also rename the project by right-clicking on the project name and hitting "Rename".

Once you've updated the project settings you can start adding your contracts. In this case we'll add an ICalculatorContract interface and end up with this:

/// Copyright (c) Microsoft Corporation.  All rights reserved.
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.AddIn.Contract;
using PipelineHints;
 
 
namespace Sample.Calculator.Contracts
{
    [System.AddIn.Pipeline.AddInContract]
    public interface ICalculatorContract : IContract
    {
        double Add(double a, double b);
        double Subtract(double a, double b);
        double Multiply(double a, double b);
        double Divide(double a, double b);
    }
}

Since the ICalculatorContract type represents an add-in, and not simply a type that is exchanged between the host and the add-in, you need to apply the System.AddIn.Pipeline.AddInContract to identify the contract as something that can be activated. Once you've added the above code just need to compile the contract and it will be ready for use by the Pipeline Builder.

If you examine the output placed in the AddInView and HostView projects you'll notice that the tool will automatically remove the "Contract" suffix from the name of all types and will drop the ".Contracts" suffix from the default namespace. You'll probably want to change the name of the assemblies as well. You can do this using the SegmentAssemblyName attribute.

UPDATED WIKI: From Blank Pipeline Project To Working Solution

JesseKaplan — Sat, 12 Jan 2008 00:08:20 GMT

Going from the Blank Contract Sample to a Working Solution

/// Copyright (c) Microsoft Corporation.  All rights reserved.
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.AddIn.Contract;
using PipelineHints;
 
 
//You should change the assembly name and default namespace for this project before you use it. 
namespace Sample.Blank.Contracts
{
   
}

Insert Image ***

Once you've updated the project settings you can start adding your contracts. In this case we'll add an ICalculatorContract interface and end up with this:

/// Copyright (c) Microsoft Corporation.  All rights reserved.
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.AddIn.Contract;
using PipelineHints;
 
 
namespace Sample.Calculator.Contracts
{
    [System.AddIn.Pipeline.AddInContract]
    public interface ICalculatorContract : IContract
    {
        double Add(double a, double b);
        double Subtract(double a, double b);
        double Multiply(double a, double b);
        double Divide(double a, double b);
    }
}

UPDATED WIKI: Using the VS Add-In

JesseKaplan — Fri, 11 Jan 2008 23:37:46 GMT

Using the VS Add-In

Start VS
Click on the Tools->Options menu item
Select the Environment->Add-In/Macros Security item
Add the path where you installed this addin to the "Add-in File Paths" list (default is c:\Program Files\Microsoft\Visual Studio Pipeline Buillder)
Restart VS

Solution Directory

Solution File
Contract Project Directory
Host Project Directory (optional)
Output directory (the name is up to you)

Contracts (your contract project should build here)

If the projects for the various pipeline segments are not part of your solution it will:

Create them in the in the directory specified

If the project being generated is not part of the solution but a directory with its name is located in the "Project Location" path then it will delete that directory

Set up the references appropriately
Set up their build paths appropriately
Add the generated source files to each project with a .generated.cs extension

If the projects for the various pipeline segments are part of your solution it will:

Reuse the existing projects
Delete all files with the .generated.cs extension
Add the generated source files to each project with a .generated.cs extension

System.Reflection.TargetInvocationException: Exception has been thrown 
by the target of an invocation. ---> System.IO.FileNotFoundException: