When the resource of an assembly is meant to be shared, that means that it will be in the global assembly cache. Once in the global assembly cache, the assembly can be used by applications such as the Business Intelligence Development Studio. A requirement of the global assembly cache is that the assembly must be strongly named. A strong name guarantees that an assembly is globally unique. A strong-named assembly has a fully qualified name that includes the assembly's name, culture, public key, and version number. The runtime uses this information to locate the assembly and differentiate it from other assemblies with the same name.

To sign an assembly with a strong name, you must have a public/private key pair. This public and private cryptographic key pair is used during compilation to create a strong-named assembly.

For more information on strong names and on the steps necessary to sign an assembly, see the following topics in the .NET Framework SDK documentation:

• Strong-Named Assemblies
  
• Creating a Key Pair
  
• Signing an Assembly with a Strong Name
  

You can easily sign your assembly with a strong name in Visual Studio during compilation. In the Project Properties dialog box, select the Signing tab. Select the option to Sign the assembly and then provide the path to the key (.snk) file.

After signing the project, you must build or rebuild the solution. First, verify the Assembly version. In Project / Properties / Application, click Assembly Information. Make sure that there are no asterisks in the assembly version number. Otherwise, on each compilation the version number increments and a separate version is created in the GAC. Additionally, when you add a task to a package, the version number of the assembly is persisted in the package. Therefore, if you use an asterisk in the assembly, you could never see the results of recompiling the task without also recreating the package, or removing and recreating the task in question in an existing package.

Now, build or rebuild the project.

To build or rebuild a single project

1. In Solution Explorer, select or open the project that you want.
   
2. On the Build menu, click Build [Project Name] or Rebuild [Project Name].
   
   • Click Build [Project Name] to build only those project components that have changed since the last build.
     
   • Click Rebuild [Project Name] to "clean" the project first, and then build the project files and all project components.
     

Most developers create custom tasks and their associated user interfaces in the same Visual Studio Solution, under separate projects. For deployment, each project should be compiled into its own DLL.

The SSIS Designer locates the tasks available for use in SSIS Designer by enumerating the files found in a directory that is created when SQL Server 2005 is installed. When the default SQL Server installation settings are used, this directory is located at C:\Program Files\Microsoft SQL Server\90\DTS\Tasks. After the custom task has been compiled, move it to this folder.

To install the task assembly into the Global Assembly Cache (GAC), use the command line tool gacutil.exe, or drag the assemblies to the %system%\assembly directory. The following command will install a component named MyTask.dll into the GAC using gacutil.exe.

gacutil /iF MyTask.dll

Close SSIS Designer before registering the component. For more information about the GAC, see Global Assembly Cache Tool (Gactutil.exe) in the .NET Framework Tools.

The last step is to add the custom task to the Control Flow toolbox. Custom tasks do not appear in the Control Flow toolbox until you add them manually. The following steps describe how to add the custom task to the toolbox.

1. Right-click the toolbox and then click Choose Items.
   
2. In the Customize Toolbox dialog box, click the SSIS Control Flow Items tab.
   
3. If the task is not displayed in the list of available tasks, click Browse, and select the custom task.
   

Tasks are dynamic link libraries (DLLs) that run in the process in which they are hosted. At design time, the host process is ordinarily Business Intelligence Development Studio. Debugging a task is accomplished by setting breakpoints in the source code and attaching to the process of the environment that is hosting the task.

The steps for debugging a custom task or other custom control flow component in BI Development Studio are the same as the steps for debugging a custom data flow component. For more information, see "Debugging a Component" in Installing and Debugging Components.

Concepts

Help and Information