Programmatically access tfs build output - vb.net

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

Related

Extracting MSDeploy Zip package using variables

I’m setting up an automated build in VSTS that will FTP the published files to my server.
I have this working but the way I’ve achieved it, I feel is hacky and non-sustainable.
the process as you can see from the screenshots will publish the artefact which consists of a readme, cmd file and a zip containing all my publish files and then I extract the ZIP with the very explicit location below.
$(Build.ArtifactStagingDirectory)\temp\Content\d_C\a\1\s\IntermittentBug\IntermittentBug\obj\Release_EukHosts\Package\PackageTmp
I’m using a hosted build server in VSTS but as the path contains
d_C\a\1\s\
I assume this will change in time. What I need is a variable to cater for this path so it will always succeed.
How can I update this to make it more efficient and sustainable?
First, as jessehouwing said that the variable is called Build.SourcesDirectory.
Regarding the path structure, the simple way is specifying /p:PackageTempRootDir="" msbuild argument in Visual Studio Build task to remove the source path structure, then the path will be like Content\D_C\PackageTmp.
On the other hand, you also can publish the web app through File System mode.
This variable is caught in a predefined variable called Build.SourcesDirectory. see the complete list of predefined variables here.
In your batch or powershell scripts this variable is available as a environment variable called %BUILD_SOURCESDIRECTORY% / $env:BUILD_SOURCESDIRECTORY.

Can node webkit build in a single windows .exe file

I have a project that need to run in a pen drive, the content is updated daily, and i need a automated way to generate a single file (.exe) to be downloaded by users.
I use this tool https://github.com/mllrsohn/node-webkit-builder, but when build for windows, the build generate multiple files ( dlls, dat ,exe ).
This break my automation because the content need to be downloaded (single file).
Any help?
As far as I know, it can't. You could try making a 7zip SFX archive and running your own program instead of an installer.
This needs to create temporal files when run (which are deleted when the program quits) and I don't think you can remove the initial prompt. If you're okay with that, it might be what you need.
Edit: You can get the necessary SFX modules here.

Windows Form VB.Net - Attaching empty Directories for Deployment

I'm creating a GUI in order to launch a batch file which then kicks off a Powershell script. The GUI compiles fine and everything works great, however when I go to deploy the file it doesn't actually include any of the empty directories my script relies on.
How can I add empty directories to be included in my published VB form during install?
I don't think you can. Why don't you just do
If Not Directory.Exists(dir) Then
Directory.Create(dir)
End If
for each directory? I would create a list of directories over which to enumerate and run this each time the application is run.
You can always use the post build step to either create the directories you need or do other logic that your program may need such as run a batch file or power-shell script
See the example below. It will create a directory Test in the output directory where the .exe is placed.

How do I Include a Powershell script when publishing my VB app?

I am writing an application in VB.NET. In the app, I have a function which calls a Powershell script and places the resulting information in a text box.
I have two issues:
How to I ensure that when my app is published, the powershell script is included?
How do I reference the script in my code?
Currently, I simply give my function the full path to the script, which is in a folder on my Desktop. Obviously, this will not work once I deploy the app to other computers.
You will need to create a Setup project to get your script in place on your target system.
A first step is to change the Build Action to Content and Copy to Output Directory to Copy always.
Your Setup project can pick up the script from the VB app build result and put it in place when installing your app.
As for your question concerning the user configurable install path: The easiest way to handle this would be to add registry entry containing the selected program file path and have your app read the path from there.

FTP only changed files in MSBuild

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!)