Are there some way to execute a SSIS Package that I have in a document library in Sharepoint?
As a guess, I'll delete if it's inaccurate, since SharePoint exposes the "Open with Explorer" option, it seems that one can operate on SP libraries like they're normal file system objects. Given that assumption, you should be able to run a package via the command line like
dtexec /file "http://server/sites/subsite/db/Shared Documents/Package.dtsx"
I don't have any packages in our Site or I'd test that. dtexec threw a package not found exception instead of flinching at the http portion so that's seems promising.
A similar question was asked on the MSDN forums and it seems like it should be possible as long as the account running the package (SQL Agent or your account) has the right permissions to SharePoint.
http://social.msdn.microsoft.com/Forums/en/sqlintegrationservices/thread/916fb8e9-63a2-43e3-8195-c09ccfeb020d
Related
I am working as part of a wider team, on an SSIS package. We use TFS for collaboration, and the package has links to .sql files amongst other things.
When I run the package manually, the package runs without any issues, as the connection manager references my directory. When someone else tries to execute the package, they get an error message "Could not find a part of the path ......... script.sql"
Is there a way to correctly reference the TFS location, so it works for everyone, or is there some other way to reference these files in SSIS, so they work for everyone in the team?
Thank you
I am trying to setup a CI process with Team Build and VS2012. I've setup the web server to accept web deployment. I've installed Web Deploy 3.0, IIS Management Services and have configured the permissions to the website dir.
I have a msbuild project that compiles, packages and then deploys the site using MSDeploy but I'm coming across a issue that seems to be happening to many but I haven't been able to find a clear answer.
The problem stems from needing to pass in the site name to MSDeploy so that the user the build server runs under can publish. Like so:
https://computername:8172/msdeploy.axd?site={websitenameonly}
I've tried various ways to include this in the MSBuild file but they all end in failure. The '=' seems to break the string and cause the {websitenameonly} to be considered as another parameter.
Has anyone successfully been able to pass in the site name via MSBuild?
The MSBuild scripts will append ?site for you, so there's no need to do it yourself.
Make sure you've set the following in your pubxml:
MSDeployPublishMethod is WMSVC
MsDeployServiceUrl is in the format https://computername:8172/msdeploy.axd
DeployIisAppPath is set to your IIS site name
You haven't set NormalizePublishSettings to false (I doubt you have, but worth checking)
I just downloaded TeamCity 7 today and decided to get it up and running for my Azure solution. I am not trying to do anything fancy (yet) and started with a very basic command line build:
msbuild /t:Publish /p:Configuration=Release;TargetProfile=Production;PublishDir=S:\HoursTracker\Deployments
This builds successfully and produces a package that looks like this*:
I then attempted to configure TeamCity in an identical fashion:
This builds successfully and produces a package that looks like this*:
What I don't understand is why there is such a huge discrepancy in the size of the MVC project. Publishing directly from Visual Studio produces the exact same result as my MSBuild command so I'm convinced that TeamCity is the odd man out. Since I assume TeamCity is not broken, can someone please educate me on how to properly configure it so that I get the expected output?
*I have renamed the package files with .zip so that the details were viewable for this post.
Ming's answer helped me solve the mystery. After inspecting the contents of the zip files, I discovered the difference was that my MSBuild package contained bin and obj folders and the TeamCity package did not.
After making this discovery, I realized that I could specify multiple targets to MSBuild and prepended "Clean" to my targets switch like so:
msbuild /t:Clean;Publish /p:Configuration=Release;TargetProfile=Production;PublishDir=S:\HoursTracker\Deployments
As expected, this removed those folders. So apparently, TeamCity specifies "Clean" implicitly for you. Mystery solved.
Windows Azure packages may be larger than we expect. You can rename the cssx file to zip and you will find out what’s inside the package. In addition to the web application’s usual files, there’re a bunch of Windows Azure files. For example, if you enable diagnostics, you will see a diagnostics folder, where you’ll find files used by Windows Azure diagnostics runtime.
Best Regards,
Ming Xu.
Why you specified x64 for msbuild runner? Try selecting tools version as well. You have not specified /p:Platform parameter. Does publish task involve rebuild?
TeamCity starts msbuild with number of /p: parameters taken from " properties and environment variables " section, plus some well-known parameters like configuration name or project name.
I'm trying to run this batch file from a windows service (running as my own user) and msbuild doesn't work. Running it directly however, works. I'm getting a buch of "The handle is invalid" on stderr from I presume vcvarsall.bat.
rem Load compilation environment
call "C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\vcvarsall.bat"
rem Load the All Solutions.sln program
msbuild "C:\AutoBuildCheckout\Other Projects\All Projects\All Projects.sln"
pause
I'm confused. Anyone have any suggestions?
-Isaac
Services in Windows Vista and higher run in a separate desktop, and therefore don't have access to stdin, stdout, and stderr. (Services can no longer 'interact with desktop'; you'll notice that option is missing from the services applet in Control Panel.)
EDIT: After the comments below... A service IMO is the wrong solution. There are continuous integration products that manage this for you, like Hudson or CruiseControl; I'm sure there are many others. See also Continuous Integration at Wikipedia for more info.
My solution was to just not call vcvarsall.bat. Instead I'm directly summoning msbuild from where it sits in the windows directory. So I got around the problem without really knowing the solution.
I have a SSIS master package, which executes several child packages. It works great, but when I deploy it to the file system on the server, I get an error code "0xC00220DE". "The system cannot find the file specified."
When I run the package on the server by double-clicking it, it works correctly. But when I use DTExec:
dtexec /FILE "d:\cmcdx\ssis\MAESTRO_FACTURACION.dtsx"
I get the mentioned error.
The package configuration is correct, and the user I'm executing the package with is administrator of the machine.
Should I deploy the packages to Sql Server? What are the best practices for deploying a master-child package? I'm running out of ideas here...
By the way, I'm running Sql Server 2005 sp3.
Solved it.
I was using relative paths to point to the child packages, and in runtime SSIS was unable to find them.
In the end I used a specific path, set in a configuration file. Then I used the deployment utility, copied everything to the server, run it by double clicking on the SSISDeploymentManifest file and changed the paths to the proper location.
Thank James and Justin for your answers.
Is the package not getting a path or location value from a package configuration file? If so make sure you include the /ConfigFile argument and the path to the config file. Another thing to possibly check is if you have any connections in the package that refer to mapped network drives, these may not work running under the different service account than your local console account.
[Edit]
Try this command line below on the server (notice the double slashes).
dtexec /FILE "d:\\cmcdx\\ssis\\MAESTRO_FACTURACION.dtsx"
There are several things that could be going wrong here. You mention that you're using a master package to run several child packages. Are all of your child packages in their proper location on the server as well?
Remember that the paths to the child packages should be variables in your master package so that those values can be changed through a configuration file on the server if need be.
You might also want to check out this set of tutorials on MSDN:
Package Deployment How-To Topics
These tutorials explain how to properly enable package configurations on the server when your package runs.