sabinio / SSISMSBuild

Contains two custom tasks; one to compile the .dtproj and the other to deploy SSIS projects.
https://bzzzt.io/2017/05/05/ssismsbuild-updated-and-moved/
Microsoft Public License
2 stars 5 forks source link

Installation requirements on build server #7

Open fmms opened 6 years ago

fmms commented 6 years ago

Hi Richie,

i have seen that in you nuget file you have just the one DLL for the task. What else do you install on the build server to have a functioning environment? So far I have been copying all DLLs that are places in ./bin/Release/ after a build. However, for sure many of these do not seem to be needed...

With this knowledge I'd like to create some documentation for this project.

Thanks Felix

RichieBzzzt commented 6 years ago

OK I really need to get on and check this. I will try do get an answer to you in the next 3 hours.

fmms commented 6 years ago

Thanks for checking.

I have been trying the last days to use ssismsbuild with ADFv2 SSIS in Azure with VSTS as build server. However, I was not able to get this working with VSTS. I have posted to the Azure Advisors internal yammer forum just this morning.

I was able to simplify the problem to a simple PowerShell test script

# idea from https://msdn.microsoft.com/en-us/library/microsoft.sqlserver.dts.runtime.package.properties.aspx
try {
Add-Type -Path "C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\IDE\PublicAssemblies\SSIS\140\Microsoft.SqlServer.ManagedDTS.dll"
} catch {
Write-Host "Message: $($_.Exception.Message)"
Write-Host "StackTrace: $($_.Exception.StackTrace)"
Write-Host "LoaderExceptions: $($_.Exception.LoaderExceptions)"
return
}

$application = New-Object Microsoft.SqlServer.Dts.Runtime.Application
$package = New-Object Microsoft.SqlServer.Dts.Runtime.Package

foreach($prop in $package.Properties) {
Write-Host $prop.Name
}

Which gives

This creates the following output:
New-Object : Exception calling ".ctor" with "0" argument(s): "An Integration Services class cannot be found. Make sure 
that Integration Services is correctly installed on the computer that is running the application. Also, make sure that 
the 64-bit version of Integration Services is installed if you are running a 64-bit application.    "
At D:\a\1\s\TFSBuildUtilities\path\Test-SsisInstallation.ps1:11 char:16
+ $application = New-Object Microsoft.SqlServer.Dts.Runtime.Application
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidOperation: (:) [New-Object], MethodInvocationException
+ FullyQualifiedErrorId : ConstructorInvokedThrowException,Microsoft.PowerShell.Commands.NewObjectCommand

The same exception is thrown by ssismsbuild -- just harder to reproduce.

This is, because there is a dependency chain from Microsoft.SqlServer.ManagedDTS.dll to Microsoft.SqlServer.DTSRuntimeWrap.dll. Microsoft.SqlServer.DTSRuntimeWrap.dll now seems to check the registry for some OLE/COM-classes and thus fails. To my understanding this classes are correctly set when installing either SSMS, SSDT, Visual Studio on a local machine.

The only way I found arround it is https://github.com/fmms/ssis-build . Which gives me a working CI onPrem and in Azure.

RichieBzzzt commented 6 years ago

OK wow the build component of that seems 100 times better than this project. I'm going to have a play around with it.

My only reservation about hte deploy is that it doesn't factor in environment variables or mapping those to the parmeters. But it's still very good.