May 16, 2017 at 12:20 pm
I must be missing something obvious. In SSIS 2012, I've got a new SSIS project with ProtectionLevel property set to DontSaveSensitive for the project and each of the six packages (.dtsx) have their ProtectionLevel set to DontSaveSensitive as well. I can deploy (using project deployment) to my development server, configure to use the variables setup in the environment and the project runs fine on dev.
Then from SSMS, I export the project creating an .ispac file. If I copy this file to another server (or on same dev server), and double click to run the deployment wizard, on the Changing protection level step get the error:
The package failed to load due to error 0xC00111008 "Error load from XML. No further detailed error information can be specified for this problem because no Events object was passed where detailed error information can be stored."
I'm clearly missing something. Any ideas?
Thanks,
Rob
May 16, 2017 at 12:40 pm
So I can copy the .ispac file from my SSDT project's \bin\Development directory and that let's me import on dev or other servers just fine. There's some security difference between the two ways of generating the .ispac -- I'm still curious if anyone has an explanation.
Thanks,
Rob
May 16, 2017 at 12:52 pm
Have you tried deploying directly from VS? I see no benefit in copying ispacs around, nor is there any need to run the wizard.
The absence of evidence is not evidence of absence.
Martin Rees
You can lead a horse to water, but a pencil must be lead.
Stan Laurel
May 16, 2017 at 1:09 pm
Permissions -- I can't see the test or prod server from the dev server that has SSDT. I've done what you suggest and just deployed directly from SSDT to different servers in other environments, but that's not an option (at least currently) here.
Thanks,
Rob
May 16, 2017 at 1:33 pm
robert.gerald.taylor - Tuesday, May 16, 2017 1:09 PMPermissions -- I can't see the test or prod server from the dev server that has SSDT. I've done what you suggest and just deployed directly from SSDT to different servers in other environments, but that's not an option (at least currently) here.
Thanks,
Rob
OK, makes sense. I seem to remember it not always being straightforward when doing this manually. Now I use a PoSh script on a CI server to do deployments to all servers, from source control, to avoid such issues.
The absence of evidence is not evidence of absence.
Martin Rees
You can lead a horse to water, but a pencil must be lead.
Stan Laurel
Viewing 5 posts - 1 through 4 (of 4 total)
You must be logged in to reply to this topic. Login to reply