I'm trying to automate a vb6 project deployment through jenkins.
Jenkins server is deployed in Windows Server 2019 running multiple successful jobs.
When I build my project through Visual Studio 6 (for debug), everything is OK.
When I build my project through command line in developer machine, everything is OK.
When I build my project inside Jenkins machine using CMD command, everything is OK.
When I build my project through Jenkins portal, using vb6 plugin, the job is successful, but some screens get wrapped.
Same screen when I build without/with Jenkins:
If I set the width/height of the form in Form_Load method, I can workaroud the problem, but is a project with tons of forms and I would like to know the source of the problem.
Related
So I am using VSTF with some On Site build agents. A Windows Machine and a Mac for Xanamarin.iOS and Xamarin.Android builds and TFS for source control
Each time the build definition runs it creates a brand new workspace where it downloads and builds my application. This means that my list of TFS workspaces grow ever increasingly and that my build agent's hard drive fills very quickly.
I have changed the Clean setting in the Repositories tab to true. Which I got from this question.
This works fine for my Windows build agent but does not work for my Mac Build agent.
Am I missing something on my mac build agent?
Aside: Currently my Mac build definition always fails but that doesnt seem to affect the Windows build agent
This sounds like a legitimate bug in the Mac/Linux agent. You should open an issue on their GitHub page:
https://github.com/Microsoft/vso-agent/issues
I have a project inside a solution and Visual Studio Team Services is setup to do continuous build.
The test project that includes the Web API project builds fine and even includes the artifacts from the web api project, but when I look at the drop folder from artifacts view it doesn't have a sub folder for the website.
This is done with a new default Visual Studio Build definition with bone stock settings. (no amount of playing around works either)
(I'd put in a screen shot but literally just create a new build definition as choose visual studio and continuous integration and click ok, and that's exactly what this is.)
The log file for the build step doesn't show that it even tries to build the csproj for the web api project and just skips right to the Tests project. (and no errors in the log either)
Going to configuration manager for that configuration (and all configurations) and the project in question is set to build.
It builds properly in that configuration with that project just fine.
It publishes from Visual Studio with that project just fine.
Any ideas why it won't build the project?
According to the information you provided, you are using a default build definition for Visual Studio CI without any other settings. This definition does not generate the web app publish files.
Try adding following MSBuild Arguments in "Visual Studio Build" step and then queue a new build:
/p:DeployOnBuild=true /p:outdir=$(build.artifactstagingdirectory)
Update:
Since you want to deploy the website by Azure Deploy from Release Management, you can just upload the deployment packages to drop. To do this, change the MSBuild Arguments to following:
/p:DeployOnBuild=true /p:WebPublishMethod=Package /p:PackageAsSingleFile=true /p:PackageLocation="$(build.artifactstagingdirectory)\\"
And then you can go to Release Managament, in the "Azure Web App Deployment" step, set "Web Deploy Package" to "$(System.DefaultWorkingDirectory)\**\ProjectName.zip".
I have a TFS 2013 build definition that recently started to act strange. Its been doing its job for over a year now without any problems.
It builds 4 different projects. Two of them are asp.net mvc/webapi projects which also are deployed via msdeploy to two separate websites on the same QA staging web server. The build is configured to use Release|Any CPU
When the build runs the dll version is set using the ApplyVersionToAssemblys powershell script.
In the build folder all the assemblies have the correct version. But in one of the deployed web sites one of the dll files "WebUI.dll" has version number 1.0.0.0 ie not the same as the same dll in build directory has which is 4.0.buildnumber
The deployed "WebUI.dll" also seems to be built in Debug mode becuase some buttons and actions are only displayed when DEBUG is defined.
If I copy the built WebUI.dll from build directory or even the PublishedWebsites directory everything works as expected.
So my question is how can MSDeploy via MSBuild create its "own" version of the WebUI.dll? (And no - the Define DEBUG constant checkbox is not checked in Release mode). The version 1.0.0 WebUI.dll cant be found anywhere on the server so I guess it must be "created" when msdeploy runs?
(The only change I've made recently is to add a new build definition which builds the same solution and runs all tests but does not deploy anything.)
UPDATE: I tried to publish from VS using the same publish profile used by the build process and that works as expected. The WebUI.dll deployed is built in release mode. The version is not applied becuase that is part of the build process but the important thing is that its the Release mode dll that is deployed and not Debug which is the case when the buildprocess does the deploy. I also tried creating a web deploy package and installed that on the local server with the same result.
So the problem is still that the WebUI.dll built in the build process is correct (Release mode and correct versioning) - but gets "replaced" during the deploy on the build server by a Debug mode and without versoning
UPDATE 2; Msbuild cmd
C:\Program Files (x86)\MSBuild\12.0\bin\amd64\MSBuild.exe /nologo /noconsolelogger "C:\Builds\2\Products\SomeApp4.Main\src\SomeApp4\Main\Source\SomeApp4.Web.sln" /nr:False /fl /flp:"logfile=C:\Builds\2\Products\SomeApp4.Main\src\SomeApp4\Main\Source\SomeApp4.Web.log;encoding=Unicode;verbosity=normal" /p:SkipInvalidConfigurations=true /p:DeployOnBuild=true /p:PublishProfile=Chicago /p:AllowUntrustedCertificate=true /p:Password=bw /m /p:OutDir="C:\Builds\2\Products\SomeApp4.Main\bin\SomeApp4.Web\\" /p:Configuration="Release" /p:Platform="Any CPU" /p:VCBuildOverride="C:\Builds\2\Products\SomeApp4.Main\src\SomeApp4\Main\Source\SomeApp4.Web.sln.Any CPU.Release.vsprops" /dl:WorkflowCentralLogger,"C:\Program Files\Microsoft Team Foundation Server 12.0\Tools\Microsoft.TeamFoundation.Build.Server.Logger.dll";"Verbosity=Normal;BuildUri=vstfs:///Build/Build/740;IgnoreDuplicateProjects=False;InformationNodeId=14;TargetsNotLogged=GetNativeManifest,GetCopyToOutputDirectoryItems,GetTargetPath;LogProjectNodes=True;LogWarnings=True;TFSUrl=http://boston.SomeCompany.local:8080/tfs/SomeCompany;"*WorkflowForwardingLogger,"C:\Program Files\Microsoft Team Foundation Server 12.0\Tools\Microsoft.TeamFoundation.Build.Server.Logger.dll";"Verbosity=Normal;" /p:BuildId="abd7db3d-4ff8-43b4-ab36-f35c6f6e5697,vstfs:///Build/Build/740" /p:BuildLabel="SomeApp4.Main_4.0.6.740_20160121_103558" /p:BuildTimestamp="Thu, 21 Jan 2016 09:35:59 GMT" /p:BuildSourceVersion="LSomeApp4.Main_4.0.6.740_20160121_103558#$/Products" /p:BuildDefinition="SomeApp4.Main"
When you change the assembly version, the version under source control won't be changed. You can only change the version which has been copied on your build agent machine. If the source of the msdeploy command point to the project in TFS, you won't get the versioned assembly.
I found the problem.
The build definition builds 4 solutions where one is the WebUI(aspnet mvc) solution and one is an Api solution (asp.net WebApi)
In the Api solution a project was referencing the WebUI project but the WebUI project wasnt in the Api solution.
MSbuild resolved the WebUI project anyways so there were no errors and build + deploy of the api solution worked. But the WebUI project was built in debug mode since it has no solution configuration in Api solution I guess
The problem when msbuild ran the api solution with deploy flag it also managed to deploy the WebUI project built in debug.
So the WebUI project was deployed twice. First the correct one from the WebUI solution and then the wrong debug WebUI compiled with the Api solution.
Doh! Is all I have to say about that.
Thanks for your help guys.
My Question: How can I run a deployment script from the TFS 2010 build template on a remote system that has only a MSTest agent running?
I know this can be done by activating the Deployment section in the test settings configuration file, but this is not flexible enough. At night a build runs. When the build is successful, a deployment script is placed at a drop location. The drop location is date, project and build definition specific. These parameters are available in the TFS build template we use.
I do not have Lab Management available, just a physical server. I would rather not spoil the physical server with an additional build agent to only do the deployment. The MSTest agent is apparently capable of running deployment scripts, but how do I use that functionality from the TFS build workflow. For example, can I use the RunDeploymentScript activity without having Lab Management?
PSExec is a great tool for running scripts on remote computers. I use this in Team Deploy that allows you to install MSIs on remote computers from Team Build. You can also run PowerShell on remote computers but it is a little more complicated to set up. Another option is to use MSDeploy. There is a command option that you can run any command on a remote computer. I usually use an InvokeProcess activity to call a PowerShell script on the build server. From the PowerShell script I have called MSDeploy to run a remote PowerShell script on a target server. It sounds bad but worked good.
You can't run the RunDeploymentScript on the target machine. You can use a modified template to deploy to a physical environemnt. Here is a good post on doing this.. The options I mentioned above do not need any agent on it. You can use the ExecuteRemoteTestRun lab management activity without Lab Management to run the MTM Tests with the Test Agent with a Test Controller that is registered to the project collection (Test Manager).
Let me know if you have any questions on any of these options.
On my local dev machine this works perfectly:
msbuild project.name.csproj /p:DeployOnBuild=true /p:DeployTarget=PipelinePreDeployCopyAllFilesToOneFolder /p:_PackageTempDir="c:\proyectos\folder1\deploy" /p:AutoParameterizationWebConfigConnectionStrings=false
I'm trying to configure a Build step in TeamCity with MSBuild, in the "Command line parameters" I'm putting this:
/p:DeployOnBuild=true /p:DeployTarget=PipelinePreDeployCopyAllFilesToOneFolder /p:_PackageTempDir="c:\proyectos\folder1\deploy" /p:AutoParameterizationWebConfigConnectionStrings=false
It runs, no errors are displayed, but files are not copied to "c:\proyectos\folder1\deploy"
Edit: I'm having the same issues with MSBuild on the command prompt, so it's not teamcity. My local dev machine is on windows 7 and the server is windows 2003
Run with /v:d or v:diag to get logging.
(Get it working local first but... In TeamCity, view the agent in the console and look at the agent detail logs for similar such logs (or just pass the same /v: flag to MSBuild via TeamCity))
You'll want to ensure that the user running the "TeamCity Build Agent Service" has write access to the relevant directories.
(FWIW, I believe the LocalSystem account has different group memberships in Server 2003 and Windows 7. We run all of our TeamCity build agents under their own "teamcity" accounts to more explicitly control permissions and allow access to network shares.)
Installing Visual Studio 2010 DOES fix this problem. But, you can also fix it by copying the appropriate build targets to your machine. Typically, on your dev machine they'll be at (Or take away the (x86) for 32 bit machines):
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.0\Web
In there you'll find a bunch of Microsoft.Web.Publishing.* targets.
Just copy those over to the equivalent location on your build machine and all will be well.
Installing Web deploy tool through web platform in the server works for me. Actually visual studio installation installs web deploy, It might be the reason why it works for #himinaya.