Scenario:
Open Visual Studio 2019 Developer Command Prompt v16.3.5
cd c:\some_solution
devenv.exe libogg.sln /Build
devenv.exe immediately exits instead of build! Very disappointed...
.
Why and how to solve?
P.S. In GUI mode VS builds libogg.sln as expected.
P.P.S. Product info:
Microsoft Visual Studio Community 2019
Version 16.3.5
VisualStudio.16.Release/16.3.5+29411.108
Microsoft .NET Framework
Version 4.8.03752
devenv.exe will work, but will not direct output to the console. Use devenv.com if you want to see the output.
Commands that begin with devenv are handled by the devenv.com utility, which delivers output through standard system streams, such as stdout and stderr. The utility determines the appropriate I/O redirection when it captures output, for example to a .txt file.
Alternatively, commands that begin with devenv.exe can use the same switches, but the devenv.com utility is bypassed. Using devenv.exe directly prevents output from appearing on the console.
https://learn.microsoft.com/en-us/visualstudio/ide/reference/devenv-command-line-switches
Yes this is exit immediately, but it is doing its operation on our backend, actually, it is building the package. you can verify this from your File Explorer. If you want to know what is exactly happening while applying devenv.exe *.sln /Build then you have to use devenv.com *.sln /Build. this command will give you a detailed log while it's running.
Related
I have a Visual Studio project that I have been automatically building in GitLab CI for quite some time without any issues. I'm building the solution simply with:
devenv.exe MySolution.sln /Build "Release|x64"
Today, the builds suddenly and silenty started to fail. I have made no changes at all and the build command provides no output either. What is going on?
The most likely cause for Visual Studio builds suddenly starting to fail is an expired Visual Studio license.
Resolving silent build failures
The reason you're not seeing any output is that you're invoking devenv.exe, which is not designed to output to stdout as it's a desktop application.
In your build scripts, you're going to want to use devenv.com. Once you do so, you'll see the following output instead:
Microsoft Visual Studio 2019 Version 16.8.3.
Copyright (C) Microsoft Corp. All rights reserved.
The license for Visual Studio has expired.
The evaluation period for this product has ended.
Resolving expired license
On your build machine, open Visual Studio and check if the license is still valid. Note however, that you need to start Visual Studio with the same user account your build runner uses.
For GitLab CI on a Windows machine, where it's running as a service, Visual Studio will run as the SYSTEM user. So you need to start is as the SYSTEM user as well.
To do so, use psexec. For example:
PsExec.exe -si "C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\Common7\IDE\devenv.com"
You will most likely be greeted by a dialog asking you to log in to update your license. Upon completion, your builds will be running smoothly again.
We have been using TFS to run automated tests. The tests run either as part of a build or on demand from a Test Plan. We are using Specflow to generate the test scenarios.
For the first month that I was executing these tests, a .TRX file would be generated that contained some logs from specflow. I could also log my own trace logs using System.Diagnostics.Trace.WriteLine. All of that would show up in the .Trx file.
The .TRX file would also show the number of tests that passed, failed, or were inconclusive. If I opened the file in Visual Studio, it would show me a Test Run panel with details on each test and their results.
Recently, however, that stopped happening. The .TRX file is still created, but it is basically empty. It says that no tests were run and all of my Trace logs dont display. TFS still shows me the correct information when I am logged in to the console, but the attached .TRX file is always 2k, meaning its just the skeleton of an xml file.
Here are some details of how we run the tests:
We have a Test Plan, so the Tests run as part of a Release. The Release contains a single Run Visual Studio Test Task
The .runSettings file only contains the TestRunParameters sections. No other settings are configured.
We are using TFS 2017 Version 2.
I thought that maybe Specflow had something to do with it, but even a simple MSTest without Specflow wont log correctly.
Some answers have suggested add /Logger:trx to the Other Console Options, but that always leaves me with a Warning stating that the Release is running on multiple agents so that settings will be ignored. Our release isnt runnin on multiple agents, so I dont know why I see that warning.
This worked until recently, and I have tried to figure out what has changed. I tried creating a brand new build, new code base, and new tests to run but it doesnt seem to matter.
Let me know what additional information you need. Thanks
I have figured out how to fix the issue, but I dont understand what exactly happened so I hope someone can fill in the blanks.
There are multiple versions of VSTest.Console.Exe on the TFS server. The one that is used when I select Visual Studio 2017 as the version is
C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\Common7\IDE\CommonExtensions\Microsoft\TestWindow\vstest.console.exe
I dont know if that is correct or not, but that is what was being used. I noticed that locally I was using a different path.
C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\Common7\IDE\CommonExtensions\Microsoft\TestWindow\vstest.console.exe
I was able to execute that version of vstest and generate TRX files locally. There is also ANOTHER vstest.console.exe located at
C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\Common7\IDE\Extensions\TestPlatform\vstest.console.exe
I believe that last one is for VSTest V2? Im not entirely sure and would love someone to clarify that.
I believe which executable you run depends on the Test Platform Version setting. I normally had it set to Latest, but I changed it to Visual Studio 2017 while trying to figure out why it wouldnt log anymore.
TLDR - The Solution
You can, alternately select Specific Location, which allows you to provide a path to the executable. I set the Path to vstest.console.exe value to C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\Common7\IDE\CommonExtensions\Microsoft\TestWindow\vstest.console.exe and everything works fine.
The only thing I can think of is that the version of Vstest under Professional (the version of Visual Studio we are using) is different from the one under BuildTools? The test would run successfully either way, but the executable under Professional also generates the Trx file. Since no details are logged, its hard to tell what is going on.
Hopefully someone can explain what is going on here, but at least anyone who has this same issue has something to try.
In TFS Test Task I know that I can manually set the location of vstest.console.exe via:
this is less than an ideal solution though since, as I update my build server, this location may become invalid. The problem that I have run into is that if I select 'Version' my build server ends up using the vstest.console at this location:
C:\Program Files (x86)\Microsoft Visual Studio\2017\ SQL\Common7\IDE\CommonExtensions\Microsoft\TestWindow
I am guessing that this SQL Folder is the SQL Server Data Tools folder that is installed on the build server. This folder location isn't generally a problem, vstest runs my unit tests and reports back on them, however, it doesn't produce a code coverage report. I initially thought that this was due to an improper configuration of the builds, however after verifying that the build was setup correctly and that the server had all of the necessary dependencies I started looking for other causes. I opened up the .trx file from one of the builds and noticed that the DataCollector logged a message that it couldn't find CodeCoverage.exe. After some more troubleshooting, I pointed my build to the location of the vstest.console shown in the image above and everything (tests, code coverage) ran fine. This leads me to believe that vstest expects the path:
C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Team Tools\Dynamic Code Coverage Tools
to exist relative to where it is run from and that directory (Dynamic Code Coverage Tools) does not exist inside the SQL folder.
Is there a way to change the path that TFS uses when the 'Version' checkbox is checked?
VsTest task uses vswhere.exe in order to determine the latest version of VS installed in the machine. Can you try to run vswhwere.exe and check which version of VS is installed at C:\Program Files (x86)\Microsoft Visual Studio\2017\ SQL folder and is it higher than other versions, also check whether its an enterprise installation or not. As code coverage is provided as part enterprise installation only.
You will be able to find vswhere.exe in agent working folder as per VSTest task version eg.
C:\Temp\Agents\127Agent_work_tasks\VSTest_ef087383-ee5e-42c7-9a53-ab56c98420f9\2.3.19\vswhere.exe
I try to configure Hudson (3.1.0) to build Delphi XE3 project (MSBuild).
Batch for build:
call "C:\Program Files (x86)\Embarcadero\RAD Studio\10.0\bin\rsvars.bat"
msbuild "X:\Tests\DelphiTest\Project1Test.dproj" /t:Build /v:minimal /p:config="Debug"
Run this batch in command line (cmd.exe) - build correct.
When I put this batch into Hudson build step faild with errors from delphi compiler:
[..]
C:\Program Files (x86)\Embarcadero\RAD Studio\10.0\bin\CodeGear.Common.Targets : warning : Expected configuration file missing - C:\Windows\system32\config\systemprofile\AppData\Roaming\Embarcadero\BDS\10.0\EnvOptions.proj
_PasCoreCompile:
Embarcadero Delphi for Win32 compiler version 24.0
Copyright (c) 1983,2012 Embarcadero Technologies, Inc.
C:\Program Files (x86)\Embarcadero\RAD Studio\10.0\Bin\CodeGear.Delphi.Targets(172,5): error E1026: File not found: 'Controls.res'
[..]
In fact I don't have missing file in this location. But I've found it in
C:\Users\<username>\AppData\Roaming\Embarcadero\BDS\10.0
So I try do dummy think like copy existing dir to missing location but it doesn't work.
I'm using: Delphi XE3 Enterprise, Win 7 Ultimate (x64)
Thanks for help.
this usually happens the first time you run MSBUILD or DCC32 on a machine which has never had the IDE gui open (bds.exe) and which has passed the mandatory startup environment configuration tasks that happen inside BDS.exe.
If you log in on Hudson or Jenkins as a Windows service using an account that has never been used for Windows logins, has never run BDS.exe, you will get this issue. The MSBUILD utility from Microsoft must invoke DCC32, which is licensed commercial software, and the Delphi command line compilation licensing and environment configuration requires that you have run the IDE as the account, and that your jenkins build account and computer is licensed properly.
Solution:
Either change Jenkins or Hudson to log in as an account that has a license to run Delphi, and has run Delphi at least once.
If you can't change the server login, then log in interactively (via remote desktop) using the account that Jenkins/Hudson is using, and configure Delphi (Rad Studio) so it runs fine from that account.
Update 2015: I am now running into a whole new class of problems related to Group Managed Service Accounts. They were working with Delphi XE8, but I am not able to get a GMSA account to work with Delphi 10 Seattle. I'll update this answer if I ever do figure out a way, but for now, I recommend conventional service accounts, not GMSAs, for Delphi continuous integration with Jenkins or Continua, or others. Also check Delphi.wikia.com for more tips: http://delphi.wikia.com/wiki/Setting_up_a_Delphi_Build_Machine
We recently ran in a similar kind of problem. We are trying to compile our projects on an jenkins. We simplified the "build" script to the following 2 lines
call "[....]Embarcadero\Studio\18.0\bin\rsvars.bat"
MSBuild.exe /p:config=Release /target:Rebuild Project2.dproj
This is building the project successful.
But when we switch to /p:config=debug the build fails with the known errors about missing *.res files. We looked up in the delphi lib/win32/ directory and realized that there are *.res files in the release folder but not in the debug folder. We now further modified the msbuild command to this:
MSBuild.exe /p:config=Release /target:Rebuild /p:ResourcePath="%BDS%\lib\win32\release" Project2.dproj
And this is compiling just fine. So apparently the compiling in debug mode lacks the path to the delphi sources (which are included in several subfolders in %BDS%\source\
So as a workaround we can compile debug builds using jenkins and simply giving delphi the *.res files from its release folder. But that can only be an intermediate solution.
Maybe this information helps someone to find a final solution which is not "Adding all subfolders of %BDS%\source into the search path" ;-)
Consider a .csproj containing the following directive:
< Import Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v10.0\WebApplications\Microsoft.WebApplication.targets" />
There's a standalone TFS Build service installed on a machine, with a default Controller and one Agent. The TFS components were installed; Visual Studio was not installed.
When compiling an ASP.NET MVC 2 Web Application (targeting .NET 4), the TFS Build service encounters an error:
C:\somepath\foo.csproj (219): The imported project "C:\Program Files\MSBuild\Microsoft\VisualStudio\v10.0\WebApplications\Microsoft.WebApplication.targets" was not found. Confirm that the path in the declaration is correct, and that the file exists on disk.
TF270015: 'MSBuild.exe' returned an unexpected exit code. Expected '0'; actual '1'.
It's true: there's no sub-directory "WebApplications" in the "C:\Program Files\MSBuild\Microsoft\VisualStudio\v10.0" directory.
It seems that this subset wasn't included in the install of the TFS Build service. TFS doesn't give any options on what pieces are installed for Build service.
What's the most appropriate way to install these artifacts, and any dependencies, on this TFS Build machine? Could this have been avoided?
Have you tried creating the path C:\Program Files\MSBuild\Microsoft\VisualStudio\v10.0\WebApplications\ manually and copying the file Microsoft.WebApplication.targets there? If Microsoft.WebApplication.targets doesn't contain references to some specific build tasks that should do the trick.
At least that worked for Visual Studio 2005.
Check for unwanted references like 'stdole.dll' in your references and remove it.
connect to tfs again (to refresh)
try to build again.
Best solution is to always install VS2010 on your build machine.