Is there a way to deploy .rdl files in structured folders that are not already on a report server? The goal is to deploy the structure from windows explorer to the target report server, which has the same structure.
I recently read this article and code, which deploys from server to server.
https://azuresql.codeplex.com/releases/view/115207
We are trying to create a build environment where the deployment of rdl files comes directly from our source control, and would like to use a script that has been as widely used as the one in the link provided.
Thanks for your time,
In the SQL Server install folder there is an executable called rs.exe. You can use this, passing it an .RSS file that contains the configuration that you want to deploy. You can then bulk deploy from your folder to Reporting Services.
RS.exe
If you have the source .rdl files in TFS you can use Team Build to process and create the .RSS and likely a zip package. You can then have it deployed by Release Management for Visual Studio 2013 through a specified release pipeline that pushed it from Dev->QA->Prod.
You can get information on how from Professional Application Lifecycle Management with Visual Studio 2013.
Related
In our solution we are interacting with SAP using the "Classic" API of the SAP RFC SDK.
We have hosted the application in Azure Services, hence not possible to place the librfc32.dll in the required path of C drive.
We have added the librfc32.dll in the solution and marked it Copy Always to the folder.
While we publish the solution locally and deploy using FTP in Azure Services, it works fine.
However when deployed using ADO pipeline, it gives the below error.
We have checked both published and ADO generated artifact and in both places the librfc32.dll is present fine.
Cannot call classic RFC API. See help for details. Please put a recent 64-bit version of librfc32.dll in your System32 folder (typically C:\Windows\System32). See SAP note 413708. Please make sure you have installed Visual C++ 2005 SP1 ATL Security Update (x64). An attempt was made to load a program with an incorrect format. (Exception from HRESULT: 0x8007000B)
Any suggestion?
All the deployments in my work place are manual. I have been looking at ways to automate all of this using MSBUILD and MS Web Deploy. What I have managed to get working is as follows:
build/compile solutions
run database migrations
deploy directly to website using ms web deploy
All from one MSBUILD script.
This differs slightly from the manual process, as when a new version of a website is deployed manually, it is put into a new folder that is datetime stamped. And then IIS is pointed to the new folder.
My question is, how would I do these last 2 actions? i.e. write to a specific folder that sits a level higher up than the folder the current website points to, and then repoint to the new folder IIS.
Web Deploy does not support this functionality directly. Thankfully it does provide the runCommand provider, which is what you'll end up using.
%windir%\system32\inetsrv\appcmd.exe is the utility you'll use to swap site directories. An example of usage can be found here: How do I change the physical path of web site in IIS7 with APPCMD?
Create a script that calls appcmd. This script will always sit on your destination server. You can either decide to include it as a part of your site deployment, or move it along into the new directory from the old one. The "web deploy user" on the destination machine needs to have the appropriate credentials and access to create directories.
In your MSBUILD script, prior to deployment, call the script on the destination server. E.g.
msdeploy.exe -verb:sync -source:runcommand="C:\path\to\wwwroot\bin\script.bat"
-dest:auto,wmsvc=https://contoso.com:8172/msdeploy.axd,username=%username%,password=%password%
Then deploy as usual
NOTE:
Try to avoid this way of deploying entirely. If you're looking to snapshot your site, consider deploying to a package (zip), and then deploying that package to your destination server. Rollbacks should be handled by deploying an older package, not by repointing to an older directory.
How do you handle the deployment of a LightSwitch application into a production environment?
i.e. the LS application has been developed, but it now needs to be installed first into Test, and then into Live.
We don't want to use the "manual" approach, i.e. use the Visual Studio Build / Publish option, rather we want to automate the deployment.
My feeling is that deployment is one of the real weak points of LightSwitch. If you are using the very simple deployment model that is build into the product, and you're doing everything within a Windows domain, the publishing wizard can do everything. But if you're deviating from the model at all LightSwitch will fight you. I'd really like to see an "advanced" deployment option that provided some configurability.
Here's how I solved the problem you're having with LightSwitch applications that are targeting web deployment:
At the beginning of the project, deploy once to each target environment using the publish wizard. This is the easiest way to get the database set up.
As new builds are deployed, use the publish wizard to deploy to a deployment package to a standard location on the local development machine.
The deployment package is just a zip file, so you can open it an drill down to where the actual binary release is. I use a powershell script to copy the binary files out of the the deployment package and in to a local SVN working directory. Note that you must not copy web.config file during this step.
Check the unpacked binary files into SVN and use SVN to manage the deployment.
Manage schema changes with SQL scripts.
With VS 2008 I always used Web Deployment Projects to build to three different environments. It is maybe not the best solution, since I still have to xcopy the built files to the server, but it is simple.
Now with VS 2010 it looks promising, but it also looks complicated. My hosting provider doesn't have Web Deploy, the newest feature and the flagship technology for deployment in VS 2010.
My question is how can I just build for each environment and copy the files over to the server? Using the Build Deployment Package will create the ZIP file and when I extract it, it will output so many files and a confusing folder structure. Does anyone have any suggestions?
There is a release of Web Deployment Projects for Visual Studio 2010. The Beta 1 release [is available][1] from the Microsoft Download Centre.
This was mentioned on the Visual Web Developer Team Blog too.
Just went from TFS 2008 to 2010 at a client site and now wondering what happened to the TFSBuild.proj files from the TeamBuildTypes folder. I've already got the builds and drops working and now I need to get the old deployments working again. We used to do this with AfterBuild targets in the TFSBuild.proj. That mechanism seems to have moved or disappeared in 2010.
Can anyone point me to an article or describe how the deployment options have changed in 2010?
Specifically, I need to support running psexec to install and enable Windows Services on remote deployment targets and I need to deploy some web sites / web services to remote IIS nodes as part of the automated builds.
EDIT: Just found this: http://blogs.msdn.com/jimlamb/archive/2009/11/03/upgrading-tfs-2008-build-definitions-to-tfs-2010.aspx I'm more than a little taken back by the breaking changes between 2008 and 2010. I'm gonna need advice on how to deploy remote sites and services in the new default build process template mechanism.
Check out Vishal Joshi's PDC talk on Deploying Web Applications with VS 2010 and MSDeploy. On his blog, you'll also find tips on building MSDeploy packages with MSBuild. You can run psexec from your MSBuild script or, potentially, from a customized build process template. With TFS 2010, you can use MSBuild and Windows Workflow to solve your build automation problems.
Alternatively, you can use the "Upgrade" build process template and continue using your TFSBuild.proj file. This is the default behavior for upgraded build definitions for backwards compatibility. In that case, your build is still primarily driven by MSBuild with just a thin workflow to allocate an agent and run MSBuild.
Another option is to use TFS 2010 Build Agent on the server that you deploy to. This is how Visual Studio Lab Management deploys.
I have written a blog post about this: Continuous deployment with TFS 2010 Build Agent