An MSBuild project copies its output to a directory on a server. Each day, only a few files change and most have an older creation date.
I can FTP this to a remote server with MSBuild tasks. But how can I do this FTP and only copy the few files that have changed?
To do this you'll need something that will manage the sync for you - that is that will keep track of what file is where and update accordingly.
We have used FTPSync to do the file sync bit very tidly for a number of sites.
From MSBuild you can call an external program - so putting the two together will probably work providing your are consistently synching from the same location (otherwise its going to be more interesting!)
Related
I'm trying to write a powershell script to allow a user to specify a tfs build id (or alternately a changeset id) and download the build output to the current directory. I have the build configured to copy the output to the server, which means only the most recent build output will be accessible in that directory. However from Visual Studio, or from the TFS Web Access, I can download the drop as a .zip file.
How can I access this .zip file programmatically (either in powershell, or even if I could figure out VB code to do this I can convert it to a powershell script)? Am I thinking about build output wrong, and there's a easier, more obvious way to handle this? Is the build output of the older builds being stored somewhere else on the server, or is it store in the database? Should I be configuring the build differently to store each build in a separate folder rather than overwriting each build in a single folder?
You can access the download zip via a properly constructed URL. For example:
https://{AccountName}.visualstudio.com/DefaultCollection/{TeamProject}/_apis/build/builds/{BuildId}/artifacts/drop?%24format=zip
I have an IIS web application with a structure roughly similar to:
wwww.mysite.com
file1.asp
file2.asp
\DotNet
file3.aspx
file3.aspx
We are setting up TeamCity to do auto deployments. I have an MSBuild build step that deploys to the \DotNet folder (the aspx files), and in a separate build configuration I have another MSBuild build step that deploys to the root (the asp files).
I want to allow MSDeploy to delete unnecessary files, e.g. if I remove file2.asp from VCS, I want it to delete it from the target IIS server.
However, I do NOT want it to wipe the \DotNet subfolder.
Can I get something more granular than the command line switch "SkipExtraFilesOnServer", or is this an all-or-nothing deal?
It turns out that the answer to my question was much simpler than I expected
When deploying to the root folder of an application using the MSDeployPublish target via MSBuild, by default, extra subfolders that happen to be on the filesystem of the target IIS server are deleted.
To avoid this, I simply moved the contents of my DotNet folder to a totally separate location under C:\InetPub, but retained my original virtual folder/application structure under IIS Mgr. Of course!
Now I can publish to either location as much as I please, and one won't try and delete the other because one is no longer a filesystem subfolder of the other.
If anything - this highlights how primitive our earlier folder structure was, and what a doofus I am for not realising.
I'm not exactly sure what you're looking for here. Are you trying to delete all the files from within the dotnet subfolder but keep the folder? Are you trying to have the delete operation never delete anything from the dotnet folder? The msdeploy sync operation is pretty smart. msdeploy will move all of your marked project assets, so assuming you don't delete the files in the dotnet folder, then you should be fine.
If you just want to exempt the dotnet folder from any delete actions, as if it were a not part of your project at all, but its in a subfolder the web server and you want to not touch it, then I would suggest using the skip option in msdeploy with wildcards. I've only used it for files, but it should work for folders too. It goes like so:
-skip:objectName=filePath,absolutePath=app_offline\.*
There's documentation here: http://technet.microsoft.com/en-us/library/dd569089%28WS.10%29.aspx
Search the page for
-skip:skipAction=
You could also add a skip setting with name of the folder you wish to not by synced, like in the following msdeploy call:
msdeploy
-verb:sync
-source:contentPath="C:\Data\Personal\My Repo\MSDeploy\MultiSkip\Source"
-dest:contentPath="C:\Data\Personal\My Repo\MSDeploy\MultiSkip\Dest"
-skip:objectName=dirPath,absolutePath="DotNet"
[I took the example from the answer to this question.]
I am in the process of creating an application to allow the automation of application deployments, (https://github.com/twistedtwig/AutomdatedDeployments#readme).
The idea being that everything is in source control, application files, application configuration as well as IIS configuration. My application allows the solution to auto deploy, (adding a post build setp to the sln / proj file), after a build to the dev machine. It will allow the CI server to auto deploy to its machine for testing as well as the CI Server pushing successful builds to QA / Test / production servers. One of the issues I have with msdeploy is the requirement of IIS to be setup with the website / application before hand, (which my app is trying to get around).
So far I can create, update and remove, app pools, websites and applications via config files automatically. I can sync files and folders fine. The last step was to use the /target:package switch in msbuild to create clean file structures for web deployments. For example I would run a command like:
msbuild.exe myMvcSite.csproj /target:clean /target:package /p:Configuration=Release /p:_PackageTempDir=C:\websites\mySite /p:PackageLocation=C:\dropLocation\mySite.zip
This creates a nice zip file with the internal file path of "C_C\wbesites\mySite" ready (as I understand it) to be sync'd to the production server.
My issue is how I deploy this zip file. I want it to be independent of any IIS information, i.e. I am simply pushing the files / folders to a location, (either on the local machine for developers, or remote for testing etc). The setup of IIS with app pools and sites etc would be taken care of separately. Some of the commands (and their output) I have tried are below:
"C:\Program Files\IIS\Microsoft Web Deploy v2\msdeploy.exe" -verb:sync -source:package="C:\Temp\deploy\installer\test\testPackage.zip" -dest:auto
Info: Adding sitemanifest (sitemanifest).
Error: The application pool that you are trying to use has the 'managedRuntimeVersion' property set to 'v2.0'. This application requires 'v4.0'.
Error count: 1.
and
"C:\Program Files\IIS\Microsoft Web Deploy v2\msdeploy.exe" -verb:sync -source:package="C:\website\installer\testPackage.zip" -dest:contentpath=C:\temp\mytest
Error: Source (sitemanifest) and destination (contentPath) are not compatible for the given operation.
Error count: 1.
The first command I am trying to let it unpack the files with the structure it has. It seems to be upset about app pool stuff though, (which I don't want it to touch).
The second I am trying to get around the "auto" bit but this isn't happy either.
I am struggling to find much information about this process.
The only way I can see how I might achieve this at the moment is to not use msdeploy for it, but to create my own task to integrate the file structure and do the file syncing my self, (not ideal).
I ended up coding around this issue, rather than being able to solve it.
I take the zip package:
unzip in a temp location
find the final path it will be going to (normally from archive.xml)
check to see if I am merging the folders or doing a clean install, (i.e. do I delete the destination folder first).
copy / push files to end location, (normally with msdeploy).
I open sourced my solution to this: https://github.com/twistedtwig/AutomatedDeployments
I think we have a problem in our FTP scripts that pull files from a remote server to a local machine. I couldn't find an answer in their knowledge base, nor scripting documentation.
We are doing an MGET *.* and then a MDELETE *.* immediately after it. I think what is happening is that, while we are copying files from the server, additional files are copied into the same directory and then the delete command deletes everything from the server. So we end up deleting file we never copied down.
Is there a straight-forward way to delete only the files that were copied, or is it going to be some sort of hack job where we generate a dynamic delete script based on what we actually copied down?
Answers that are product specific would be much appreciated!
Here were the options that I came up with and what I ended up doing.
Rename the extension on the server, copy the renamed files, and then delete the renamed files. This could not work because there is no FTP rename command that works with wildcards (Windows rename command will by the way).
Move the files to a subdirectory on the server, copy the files from that location, and then delete from the remote location. This could not work because there is no FTP command to move the files on the remote server.
Copy the files down in one script and SHELL a batch file on the local side that dynamically builds a script to connect to the server and delete the files that were copied down. This is the solution I ended up using to solve this problem.
I have written a program on Visual Basic. In the debug folder, there are many files:
Database1.mdf
Database1_log.ldf
MyData.Designer.vb
MyData.xsc
MyData.xsd
MyData.xss
WindowsApplication1.exe
WindowsApplication1.config
WindowsApplication1.pdb
WindowsApplication1.vshost
WindowsApplication1.vshost.exe
WindowsApplication1.vshost.exe.manifest
WindowsApplication1.xml
I want to publish my program. Are all of those files necessary for the program? Which of them are used for my database?
Because I want to put a button in my program that backs up the database. Which files must be backed up?
First of all, you should publish the Release version of your software, not the debug version so the files will be a bit different. As for which files to publish, if you use the Setup project you will be able to select the files based upon what your application needs. For example, it looks like you are including database files with your application (Database1.mdf and Database1_log.ldf). You could add these files to the setup project.
The setup project will know to include your exe and your config file (unless you tell it not to) so you will be covered there. Here is a video and a written walkthrough of how to create a Setup project:
http://msdn.microsoft.com/en-us/library/ms241903.aspx
http://www.youtube.com/watch?v=Lcue0jo41AM
As for your PDB files, these are the Program Database Files that are used for debugging (and should never be give to the customer/end user).
http://msdn.microsoft.com/en-us/library/ms241903.aspx
As for backing up your database, back up the MDF and LDF files.
No, all of the files above are from your debug compile output. You can change what is output by changing your build configuration. Go to Build, Configuration Manager and switch to Release. It's also on the toolbar.
In general your ProjectName.exe (but not the .vshost.exe), .config (but not the .vshost.exe.config) and MDF/LDF files are needed for publishing. You also have an XSD File which will also be needed.
The MDF/LDF files are your database.