Reusing package configuration file across all packages in a solution?

I have 5 packages in a solution.

For 1st package, I add a package configuration file (xml) named common.dtsConfig containing only Database Connection configurations.
For the same package, I add another package configuration file names first.dtsConfig containing configurations specific to 1st package.

Now for 2nd package, when I reuse from existing package configuration (common.dtsConfg) with same name, it allows me to do that. I also create a package specific configuration file for 2nd package.

And so on for all 5 packages.

This works fine for development. If my database user/password changes, I edit onyl one file i.e. common.dtsConfig.

But, when I want to create the deployment utility, it fails by throwing error that "cannot copy common.dtsConfig from <src_directory> to .\bin\Deployment because it already exists". Due to this failure, I do not get the DTSInstall.EXE.

Surprisingly, this was working with June CTP and has failed with September CTP.

What should I do to reuse the package configuration file across all packages for deployment with September CTP?

thanks,
Nitesh

This is a known problem.

We fail to create a deployment manifest if 2 packages in the project share the same config file

Problem Description:

Build of a SSIS project with duplicate package config files reports the following –

Error 1 System.ApplicationException: Could not copy file "C:\VITAL\Prosjekter\Test\SmallProject\connectionLOG.dtsConfig" to the deployment utility output directory "C:\VITAL\Prosjekter\Test\SmallProject\bin\Deployment". > System.IO.IOException: The file 'C:\VITAL\Prosjekter\Test\SmallProject\bin\Deployment\connectionLOG.dtsConfig' already exists.

and as a consequence the deployment manifest file is not created and some of the package config files may not be copied to the deployment folder.

Workaround:

Create Proj.SSISDeploymentManifest manually using below template. Additionally verify that all config files and miscellaneous files (if you have it in your project) are present in deployment folder and copy in those that are missing.

<?xml version="1.0" ?>

- <DTSDeploymentManifest GeneratedBy="REDMOND\usr" GeneratedFromProjectName="Integration Services Project15" GeneratedDate="2005-09-20T16:17:42.4195337-07:00" AllowConfigurationChanges="true">

<Package>Package1.dtsx</Package>

<Package>Package.dtsx</Package>

<ConfigurationFile>cp.xml</ConfigurationFile>

<ConfigurationFile>cc.xml</ConfigurationFile>

</DTSDeploymentManifest>

Resolution:
We will fix the problem in SP1.

For meantime we consider releasing a QFE

|||

I have 2 packages within a project that each have their own config file. When I build them and have the deployment package created, it doesn't put a DTSInstall.exe file in the directory.

I haven't created a deployment package since the June CTP, so I'm wondering if this has changed? I see some posts out there referring to DTUtil, should I be using that instead, or can I just copy the packages, change the config file settings and I'll be set?

Thanks in advance for your help.

-Chris

|||Just downloaded SP1. I dont see this fixed.|||

I am experiencing the same problem even after the installation of the Cumulative Hotfix 2153.

Regards,
Yitzhak Khabinsky

|||

Jamie, what is your word on the subject?

I know that you are using shared config files quite extensively.

Microsoft’s article (Article ID: 910419) mistakenly claims that it is fixed:

http://support.microsoft.com/?kbid=910419.

FIX: You receive an error message when you try to build a project for deployment and the project contains multiple packages that are configured to use a shared configuration file in SQL Server 2005 Integration Services

Regards,

Yitzhak

|||

Yitzhak,

Up to now I have never used the deployment wizard so have not come across the problem.

-Jamie

|||

The error actually is happening during the Build process

It is very easy to reproduce.

BIDS project should have a couple of SSIS packages. Shared *.dtsConfig file should be explicitly added to the project. After that the config file shows up under the Miscellaneous node on the project tree. Right click on the SSIS project node and select Build option. The error shows up in the Output window.

Regards,

Yitzhak

|||Hi has anyone checked out the hotfix to see if the issue is resolved?|||I'm still having this issue as well. I installed service pack 1 a while ago. Is MS going to fix this soon? I use SSIS a lot and have found source control options VERY lacking. My company paid a lot of money to get TFS, and I'm not seeing a lot of value where SSIS is concerned.|||

I checked it out today. It did NOT work for me. I still get the same error.

|||

I don't know if this would help; but until know I always have used .dtsx package files and never got to use the deployment wizard; and hat is because copying the .dtx and config files to the target destination is just that easy that I have not bothered to learn about wizard. I guess my suggestion here is not to use the deployment wizard.

|||

Rafael Salas wrote:

I don't know if this would help; but until know I always have used .dtsx package files and never got to use the deployment wizard; and hat is because copying the .dtx and config files to the target destination is just that easy that I have not bothered to learn about wizard. I guess my suggestion here is not to use the deployment wizard.

I concur with Rafael. We're a *little* bit more scientific than that because we use WiX to build our deployment MSIs. I never go near the deployment wizard.

The beauty of WiX is that it is MSBuild compliant which means it can run in conjunction with TFS so all our MSIs are getting built using continuous integration (that's in answer to the guy that mentioned TFS).

Sorry, I know that's not much use to the people on this thread that are experiencing grief. It may be worth posing on another thread the question "is this fixed in SP2". The guy on this thread that replied from Microsoft (Nick Berezansky) no longer works on the SSIS team.

-Jamie

|||

Not fixed in SP2 - just tested it.

I realize this may not be an optimal solution, but have you tried removing the *.dtsconfig from the project (that is, don't include it in the misc. files). When I do this, the project builds with no errors, and the deployment utility is created with the *.dtsconfig file in the Deployment folder. The file can still be under source control, through the source code explorer with TFS, or VSS, or whatever tool you are using.

In general, though, I'd agree with Jamie and Rafael on this. I haven't used the deployment wizard since the first iteration of my first SSIS project.

Reusing package configuration file across all packages in a solution?

I have 5 packages in a solution.

For 1st package, I add a package configuration file (xml) named common.dtsConfig containing only Database Connection configurations.
For the same package, I add another package configuration file names first.dtsConfig containing configurations specific to 1st package.

Now for 2nd package, when I reuse from existing package configuration (common.dtsConfg) with same name, it allows me to do that. I also create a package specific configuration file for 2nd package.

And so on for all 5 packages.

This works fine for development. If my database user/password changes, I edit onyl one file i.e. common.dtsConfig.

But, when I want to create the deployment utility, it fails by throwing error that "cannot copy common.dtsConfig from <src_directory> to .\bin\Deployment because it already exists". Due to this failure, I do not get the DTSInstall.EXE.

Surprisingly, this was working with June CTP and has failed with September CTP.

What should I do to reuse the package configuration file across all packages for deployment with September CTP?

thanks,
Nitesh

This is a known problem.

We fail to create a deployment manifest if 2 packages in the project share the same config file

Problem Description:

Build of a SSIS project with duplicate package config files reports the following –

Error 1 System.ApplicationException: Could not copy file "C:\VITAL\Prosjekter\Test\SmallProject\connectionLOG.dtsConfig" to the deployment utility output directory "C:\VITAL\Prosjekter\Test\SmallProject\bin\Deployment". > System.IO.IOException: The file 'C:\VITAL\Prosjekter\Test\SmallProject\bin\Deployment\connectionLOG.dtsConfig' already exists.

and as a consequence the deployment manifest file is not created and some of the package config files may not be copied to the deployment folder.

Workaround:

Create Proj.SSISDeploymentManifest manually using below template. Additionally verify that all config files and miscellaneous files (if you have it in your project) are present in deployment folder and copy in those that are missing.

<?xml version="1.0" ?>

- <DTSDeploymentManifest GeneratedBy="REDMOND\usr" GeneratedFromProjectName="Integration Services Project15" GeneratedDate="2005-09-20T16:17:42.4195337-07:00" AllowConfigurationChanges="true">

<Package>Package1.dtsx</Package>

<Package>Package.dtsx</Package>

<ConfigurationFile>cp.xml</ConfigurationFile>

<ConfigurationFile>cc.xml</ConfigurationFile>

</DTSDeploymentManifest>

Resolution:
We will fix the problem in SP1.

For meantime we consider releasing a QFE

|||

I have 2 packages within a project that each have their own config file. When I build them and have the deployment package created, it doesn't put a DTSInstall.exe file in the directory.

I haven't created a deployment package since the June CTP, so I'm wondering if this has changed? I see some posts out there referring to DTUtil, should I be using that instead, or can I just copy the packages, change the config file settings and I'll be set?

Thanks in advance for your help.

-Chris

|||Just downloaded SP1. I dont see this fixed.|||

I am experiencing the same problem even after the installation of the Cumulative Hotfix 2153.

Regards,
Yitzhak Khabinsky

|||

Jamie, what is your word on the subject?

I know that you are using shared config files quite extensively.

Microsoft’s article (Article ID: 910419) mistakenly claims that it is fixed:

http://support.microsoft.com/?kbid=910419.

FIX: You receive an error message when you try to build a project for deployment and the project contains multiple packages that are configured to use a shared configuration file in SQL Server 2005 Integration Services

Regards,

Yitzhak

|||

Yitzhak,

Up to now I have never used the deployment wizard so have not come across the problem.

-Jamie

|||

The error actually is happening during the Build process

It is very easy to reproduce.

BIDS project should have a couple of SSIS packages. Shared *.dtsConfig file should be explicitly added to the project. After that the config file shows up under the Miscellaneous node on the project tree. Right click on the SSIS project node and select Build option. The error shows up in the Output window.

Regards,

Yitzhak

|||Hi has anyone checked out the hotfix to see if the issue is resolved?|||I'm still having this issue as well. I installed service pack 1 a while ago. Is MS going to fix this soon? I use SSIS a lot and have found source control options VERY lacking. My company paid a lot of money to get TFS, and I'm not seeing a lot of value where SSIS is concerned.|||

I checked it out today. It did NOT work for me. I still get the same error.

|||

I don't know if this would help; but until know I always have used .dtsx package files and never got to use the deployment wizard; and hat is because copying the .dtx and config files to the target destination is just that easy that I have not bothered to learn about wizard. I guess my suggestion here is not to use the deployment wizard.

|||

Rafael Salas wrote:

I don't know if this would help; but until know I always have used .dtsx package files and never got to use the deployment wizard; and hat is because copying the .dtx and config files to the target destination is just that easy that I have not bothered to learn about wizard. I guess my suggestion here is not to use the deployment wizard.

I concur with Rafael. We're a *little* bit more scientific than that because we use WiX to build our deployment MSIs. I never go near the deployment wizard.

The beauty of WiX is that it is MSBuild compliant which means it can run in conjunction with TFS so all our MSIs are getting built using continuous integration (that's in answer to the guy that mentioned TFS).

Sorry, I know that's not much use to the people on this thread that are experiencing grief. It may be worth posing on another thread the question "is this fixed in SP2". The guy on this thread that replied from Microsoft (Nick Berezansky) no longer works on the SSIS team.

-Jamie

|||

Not fixed in SP2 - just tested it.

I realize this may not be an optimal solution, but have you tried removing the *.dtsconfig from the project (that is, don't include it in the misc. files). When I do this, the project builds with no errors, and the deployment utility is created with the *.dtsconfig file in the Deployment folder. The file can still be under source control, through the source code explorer with TFS, or VSS, or whatever tool you are using.

In general, though, I'd agree with Jamie and Rafael on this. I haven't used the deployment wizard since the first iteration of my first SSIS project.

Reusing package configuration file across all packages in a solution?

I have 5 packages in a solution.

For 1st package, I add a package configuration file (xml) named common.dtsConfig containing only Database Connection configurations.
For the same package, I add another package configuration file names first.dtsConfig containing configurations specific to 1st package.

Now for 2nd package, when I reuse from existing package configuration (common.dtsConfg) with same name, it allows me to do that. I also create a package specific configuration file for 2nd package.

And so on for all 5 packages.

This works fine for development. If my database user/password changes, I edit onyl one file i.e. common.dtsConfig.

But, when I want to create the deployment utility, it fails by throwing error that "cannot copy common.dtsConfig from <src_directory> to .\bin\Deployment because it already exists". Due to this failure, I do not get the DTSInstall.EXE.

Surprisingly, this was working with June CTP and has failed with September CTP.

What should I do to reuse the package configuration file across all packages for deployment with September CTP?

thanks,
Nitesh

This is a known problem.

We fail to create a deployment manifest if 2 packages in the project share the same config file

Problem Description:

Build of a SSIS project with duplicate package config files reports the following –

Error 1 System.ApplicationException: Could not copy file "C:\VITAL\Prosjekter\Test\SmallProject\connectionLOG.dtsConfig" to the deployment utility output directory "C:\VITAL\Prosjekter\Test\SmallProject\bin\Deployment". > System.IO.IOException: The file 'C:\VITAL\Prosjekter\Test\SmallProject\bin\Deployment\connectionLOG.dtsConfig' already exists.

and as a consequence the deployment manifest file is not created and some of the package config files may not be copied to the deployment folder.

Workaround:

Create Proj.SSISDeploymentManifest manually using below template. Additionally verify that all config files and miscellaneous files (if you have it in your project) are present in deployment folder and copy in those that are missing.

<?xml version="1.0" ?>

- <DTSDeploymentManifest GeneratedBy="REDMOND\usr" GeneratedFromProjectName="Integration Services Project15" GeneratedDate="2005-09-20T16:17:42.4195337-07:00" AllowConfigurationChanges="true">

<Package>Package1.dtsx</Package>

<Package>Package.dtsx</Package>

<ConfigurationFile>cp.xml</ConfigurationFile>

<ConfigurationFile>cc.xml</ConfigurationFile>

</DTSDeploymentManifest>

Resolution:
We will fix the problem in SP1.

For meantime we consider releasing a QFE

|||

I have 2 packages within a project that each have their own config file. When I build them and have the deployment package created, it doesn't put a DTSInstall.exe file in the directory.

I haven't created a deployment package since the June CTP, so I'm wondering if this has changed? I see some posts out there referring to DTUtil, should I be using that instead, or can I just copy the packages, change the config file settings and I'll be set?

Thanks in advance for your help.

-Chris

|||Just downloaded SP1. I dont see this fixed.|||

I am experiencing the same problem even after the installation of the Cumulative Hotfix 2153.

Regards,
Yitzhak Khabinsky

|||

Jamie, what is your word on the subject?

I know that you are using shared config files quite extensively.

Microsoft’s article (Article ID: 910419) mistakenly claims that it is fixed:

http://support.microsoft.com/?kbid=910419.

FIX: You receive an error message when you try to build a project for deployment and the project contains multiple packages that are configured to use a shared configuration file in SQL Server 2005 Integration Services

Regards,

Yitzhak

|||

Yitzhak,

Up to now I have never used the deployment wizard so have not come across the problem.

-Jamie

|||

The error actually is happening during the Build process

It is very easy to reproduce.

BIDS project should have a couple of SSIS packages. Shared *.dtsConfig file should be explicitly added to the project. After that the config file shows up under the Miscellaneous node on the project tree. Right click on the SSIS project node and select Build option. The error shows up in the Output window.

Regards,

Yitzhak

|||Hi has anyone checked out the hotfix to see if the issue is resolved?|||I'm still having this issue as well. I installed service pack 1 a while ago. Is MS going to fix this soon? I use SSIS a lot and have found source control options VERY lacking. My company paid a lot of money to get TFS, and I'm not seeing a lot of value where SSIS is concerned.|||

I checked it out today. It did NOT work for me. I still get the same error.

|||

I don't know if this would help; but until know I always have used .dtsx package files and never got to use the deployment wizard; and hat is because copying the .dtx and config files to the target destination is just that easy that I have not bothered to learn about wizard. I guess my suggestion here is not to use the deployment wizard.

|||

Rafael Salas wrote:

I don't know if this would help; but until know I always have used .dtsx package files and never got to use the deployment wizard; and hat is because copying the .dtx and config files to the target destination is just that easy that I have not bothered to learn about wizard. I guess my suggestion here is not to use the deployment wizard.

I concur with Rafael. We're a *little* bit more scientific than that because we use WiX to build our deployment MSIs. I never go near the deployment wizard.

The beauty of WiX is that it is MSBuild compliant which means it can run in conjunction with TFS so all our MSIs are getting built using continuous integration (that's in answer to the guy that mentioned TFS).

Sorry, I know that's not much use to the people on this thread that are experiencing grief. It may be worth posing on another thread the question "is this fixed in SP2". The guy on this thread that replied from Microsoft (Nick Berezansky) no longer works on the SSIS team.

-Jamie

|||

Not fixed in SP2 - just tested it.

I realize this may not be an optimal solution, but have you tried removing the *.dtsconfig from the project (that is, don't include it in the misc. files). When I do this, the project builds with no errors, and the deployment utility is created with the *.dtsconfig file in the Deployment folder. The file can still be under source control, through the source code explorer with TFS, or VSS, or whatever tool you are using.

In general, though, I'd agree with Jamie and Rafael on this. I haven't used the deployment wizard since the first iteration of my first SSIS project.

Reusing package configuration file across all packages in a solution?

I have 5 packages in a solution.

For 1st package, I add a package configuration file (xml) named common.dtsConfig containing only Database Connection configurations.
For the same package, I add another package configuration file names first.dtsConfig containing configurations specific to 1st package.

Now for 2nd package, when I reuse from existing package configuration (common.dtsConfg) with same name, it allows me to do that. I also create a package specific configuration file for 2nd package.

And so on for all 5 packages.

This works fine for development. If my database user/password changes, I edit onyl one file i.e. common.dtsConfig.

But, when I want to create the deployment utility, it fails by throwing error that "cannot copy common.dtsConfig from <src_directory> to .\bin\Deployment because it already exists". Due to this failure, I do not get the DTSInstall.EXE.

Surprisingly, this was working with June CTP and has failed with September CTP.

What should I do to reuse the package configuration file across all packages for deployment with September CTP?

thanks,
Nitesh

This is a known problem.

We fail to create a deployment manifest if 2 packages in the project share the same config file

Problem Description:

Build of a SSIS project with duplicate package config files reports the following –

Error 1 System.ApplicationException: Could not copy file "C:\VITAL\Prosjekter\Test\SmallProject\connectionLOG.dtsConfig" to the deployment utility output directory "C:\VITAL\Prosjekter\Test\SmallProject\bin\Deployment". > System.IO.IOException: The file 'C:\VITAL\Prosjekter\Test\SmallProject\bin\Deployment\connectionLOG.dtsConfig' already exists.

and as a consequence the deployment manifest file is not created and some of the package config files may not be copied to the deployment folder.

Workaround:

Create Proj.SSISDeploymentManifest manually using below template. Additionally verify that all config files and miscellaneous files (if you have it in your project) are present in deployment folder and copy in those that are missing.

<?xml version="1.0" ?>

- <DTSDeploymentManifest GeneratedBy="REDMOND\usr" GeneratedFromProjectName="Integration Services Project15" GeneratedDate="2005-09-20T16:17:42.4195337-07:00" AllowConfigurationChanges="true">

<Package>Package1.dtsx</Package>

<Package>Package.dtsx</Package>

<ConfigurationFile>cp.xml</ConfigurationFile>

<ConfigurationFile>cc.xml</ConfigurationFile>

</DTSDeploymentManifest>

Resolution:
We will fix the problem in SP1.

For meantime we consider releasing a QFE

|||

I have 2 packages within a project that each have their own config file. When I build them and have the deployment package created, it doesn't put a DTSInstall.exe file in the directory.

I haven't created a deployment package since the June CTP, so I'm wondering if this has changed? I see some posts out there referring to DTUtil, should I be using that instead, or can I just copy the packages, change the config file settings and I'll be set?

Thanks in advance for your help.

-Chris

|||Just downloaded SP1. I dont see this fixed.|||

I am experiencing the same problem even after the installation of the Cumulative Hotfix 2153.

Regards,
Yitzhak Khabinsky

|||

Jamie, what is your word on the subject?

I know that you are using shared config files quite extensively.

Microsoft’s article (Article ID: 910419) mistakenly claims that it is fixed:

http://support.microsoft.com/?kbid=910419.

FIX: You receive an error message when you try to build a project for deployment and the project contains multiple packages that are configured to use a shared configuration file in SQL Server 2005 Integration Services

Regards,

Yitzhak

|||

Yitzhak,

Up to now I have never used the deployment wizard so have not come across the problem.

-Jamie

|||

The error actually is happening during the Build process

It is very easy to reproduce.

BIDS project should have a couple of SSIS packages. Shared *.dtsConfig file should be explicitly added to the project. After that the config file shows up under the Miscellaneous node on the project tree. Right click on the SSIS project node and select Build option. The error shows up in the Output window.

Regards,

Yitzhak

|||Hi has anyone checked out the hotfix to see if the issue is resolved?|||I'm still having this issue as well. I installed service pack 1 a while ago. Is MS going to fix this soon? I use SSIS a lot and have found source control options VERY lacking. My company paid a lot of money to get TFS, and I'm not seeing a lot of value where SSIS is concerned.|||

I checked it out today. It did NOT work for me. I still get the same error.

|||

I don't know if this would help; but until know I always have used .dtsx package files and never got to use the deployment wizard; and hat is because copying the .dtx and config files to the target destination is just that easy that I have not bothered to learn about wizard. I guess my suggestion here is not to use the deployment wizard.

|||

Rafael Salas wrote:

I don't know if this would help; but until know I always have used .dtsx package files and never got to use the deployment wizard; and hat is because copying the .dtx and config files to the target destination is just that easy that I have not bothered to learn about wizard. I guess my suggestion here is not to use the deployment wizard.

I concur with Rafael. We're a *little* bit more scientific than that because we use WiX to build our deployment MSIs. I never go near the deployment wizard.

The beauty of WiX is that it is MSBuild compliant which means it can run in conjunction with TFS so all our MSIs are getting built using continuous integration (that's in answer to the guy that mentioned TFS).

Sorry, I know that's not much use to the people on this thread that are experiencing grief. It may be worth posing on another thread the question "is this fixed in SP2". The guy on this thread that replied from Microsoft (Nick Berezansky) no longer works on the SSIS team.

-Jamie

|||

Not fixed in SP2 - just tested it.

I realize this may not be an optimal solution, but have you tried removing the *.dtsconfig from the project (that is, don't include it in the misc. files). When I do this, the project builds with no errors, and the deployment utility is created with the *.dtsconfig file in the Deployment folder. The file can still be under source control, through the source code explorer with TFS, or VSS, or whatever tool you are using.

In general, though, I'd agree with Jamie and Rafael on this. I haven't used the deployment wizard since the first iteration of my first SSIS project.

Reusing package configuration file across all packages in a solution?

I have 5 packages in a solution.

For 1st package, I add a package configuration file (xml) named common.dtsConfig containing only Database Connection configurations.
For the same package, I add another package configuration file names first.dtsConfig containing configurations specific to 1st package.

Now for 2nd package, when I reuse from existing package configuration (common.dtsConfg) with same name, it allows me to do that. I also create a package specific configuration file for 2nd package.

And so on for all 5 packages.

This works fine for development. If my database user/password changes, I edit onyl one file i.e. common.dtsConfig.

But, when I want to create the deployment utility, it fails by throwing error that "cannot copy common.dtsConfig from <src_directory> to .\bin\Deployment because it already exists". Due to this failure, I do not get the DTSInstall.EXE.

Surprisingly, this was working with June CTP and has failed with September CTP.

What should I do to reuse the package configuration file across all packages for deployment with September CTP?

thanks,
Nitesh

This is a known problem.

We fail to create a deployment manifest if 2 packages in the project share the same config file

Problem Description:

Build of a SSIS project with duplicate package config files reports the following –

Error 1 System.ApplicationException: Could not copy file "C:\VITAL\Prosjekter\Test\SmallProject\connectionLOG.dtsConfig" to the deployment utility output directory "C:\VITAL\Prosjekter\Test\SmallProject\bin\Deployment". > System.IO.IOException: The file 'C:\VITAL\Prosjekter\Test\SmallProject\bin\Deployment\connectionLOG.dtsConfig' already exists.

and as a consequence the deployment manifest file is not created and some of the package config files may not be copied to the deployment folder.

Workaround:

Create Proj.SSISDeploymentManifest manually using below template. Additionally verify that all config files and miscellaneous files (if you have it in your project) are present in deployment folder and copy in those that are missing.

<?xml version="1.0" ?>

- <DTSDeploymentManifest GeneratedBy="REDMOND\usr" GeneratedFromProjectName="Integration Services Project15" GeneratedDate="2005-09-20T16:17:42.4195337-07:00" AllowConfigurationChanges="true">

<Package>Package1.dtsx</Package>

<Package>Package.dtsx</Package>

<ConfigurationFile>cp.xml</ConfigurationFile>

<ConfigurationFile>cc.xml</ConfigurationFile>

</DTSDeploymentManifest>

Resolution:
We will fix the problem in SP1.

For meantime we consider releasing a QFE

|||

I have 2 packages within a project that each have their own config file. When I build them and have the deployment package created, it doesn't put a DTSInstall.exe file in the directory.

I haven't created a deployment package since the June CTP, so I'm wondering if this has changed? I see some posts out there referring to DTUtil, should I be using that instead, or can I just copy the packages, change the config file settings and I'll be set?

Thanks in advance for your help.

-Chris

|||Just downloaded SP1. I dont see this fixed.|||

I am experiencing the same problem even after the installation of the Cumulative Hotfix 2153.

Regards,
Yitzhak Khabinsky

|||

Jamie, what is your word on the subject?

I know that you are using shared config files quite extensively.

Microsoft’s article (Article ID: 910419) mistakenly claims that it is fixed:

http://support.microsoft.com/?kbid=910419.

FIX: You receive an error message when you try to build a project for deployment and the project contains multiple packages that are configured to use a shared configuration file in SQL Server 2005 Integration Services

Regards,

Yitzhak

|||

Yitzhak,

Up to now I have never used the deployment wizard so have not come across the problem.

-Jamie

|||

The error actually is happening during the Build process

It is very easy to reproduce.

BIDS project should have a couple of SSIS packages. Shared *.dtsConfig file should be explicitly added to the project. After that the config file shows up under the Miscellaneous node on the project tree. Right click on the SSIS project node and select Build option. The error shows up in the Output window.

Regards,

Yitzhak

|||Hi has anyone checked out the hotfix to see if the issue is resolved?|||I'm still having this issue as well. I installed service pack 1 a while ago. Is MS going to fix this soon? I use SSIS a lot and have found source control options VERY lacking. My company paid a lot of money to get TFS, and I'm not seeing a lot of value where SSIS is concerned.|||

I checked it out today. It did NOT work for me. I still get the same error.

|||

I don't know if this would help; but until know I always have used .dtsx package files and never got to use the deployment wizard; and hat is because copying the .dtx and config files to the target destination is just that easy that I have not bothered to learn about wizard. I guess my suggestion here is not to use the deployment wizard.

|||

Rafael Salas wrote:

I don't know if this would help; but until know I always have used .dtsx package files and never got to use the deployment wizard; and hat is because copying the .dtx and config files to the target destination is just that easy that I have not bothered to learn about wizard. I guess my suggestion here is not to use the deployment wizard.

I concur with Rafael. We're a *little* bit more scientific than that because we use WiX to build our deployment MSIs. I never go near the deployment wizard.

The beauty of WiX is that it is MSBuild compliant which means it can run in conjunction with TFS so all our MSIs are getting built using continuous integration (that's in answer to the guy that mentioned TFS).

Sorry, I know that's not much use to the people on this thread that are experiencing grief. It may be worth posing on another thread the question "is this fixed in SP2". The guy on this thread that replied from Microsoft (Nick Berezansky) no longer works on the SSIS team.

-Jamie

|||

Not fixed in SP2 - just tested it.

I realize this may not be an optimal solution, but have you tried removing the *.dtsconfig from the project (that is, don't include it in the misc. files). When I do this, the project builds with no errors, and the deployment utility is created with the *.dtsconfig file in the Deployment folder. The file can still be under source control, through the source code explorer with TFS, or VSS, or whatever tool you are using.

In general, though, I'd agree with Jamie and Rafael on this. I haven't used the deployment wizard since the first iteration of my first SSIS project.

Reuse of report elements

I am working on a project developing a fairly large number of reports with a team of developers. Many of these reports have common elements and code, such as common headers with user-selectable colors. Additionally, many of the common parts of the reports are at mockup stage currently, and many features will have to be added to the reports as time goes on.

We're attempting to create a generalized framework that will minimize the duplication of effort as we develop these reports, and as we go back and modify or fix them later.

What is the best way to approach this?

My first attempt was to create a report template and base all the reports off of the same template. That was fine for the first pass, but as we need to make changes later, they will not be propagated to the already existing reports.

My second attempt was to have each componant of that template reference a subreport, so that changes to the actual report template will be minimized as we go forward. This works great for minimizeing work, but it appears that you lose many features with the use of subreports, and there seems to be a pretty serious performance impact as well. I have posted about one such issue here: Pagination

If anyone has pointers about how to go about this, and where I should start, they would be greatly apreciated!

You can't link common bits into a report unfortunately. IMO your best option is to keep using a template report as your base. Because reports are deployed to a RS server, you can't just update a file and expect all the reports to pick it up, the change has to be added to the reports and then they should be redeployed. I do believe there are ways to change the *styles* of already deployed reports, there are some css files you can tweak under the Reports and ReportServer virtual dirs in IIS.

You just have to make sure that whoever orders the changes knows the true cost of implementing it.

|||

Well, the subreport method got us most of the way there, but we had to do things that way.

The only part that I couldn't figure out was the ability to specify the report source for the subreport as a parameter or field. That way we could share the base report across our projects (using sourcesafe) and changes to it would propagate to all the reports (yes, we'd still have to redeploy, but the issue we're trying to avoid is the need to manually edit things, where a change could be forgotten on one report and introduce a bug.)