MSTest from command line - powershell

I am trying to run MSTest from command line in powershell.
mstest /testcontainer:Common.Tests.dll
I am in the project bin/debug folder. It opens a new command window and the window closes either with no output or output that I can't read, as a result of the window immediately closing. The test run successfully in Visual Studio and the project builds successfully using MSBuild and in Visual Studio. I assume that something is breaking but I have no idea how to determine what it could be.
I am using VS 14.0.
I have also tried vstest.console with the same result.

Well, one way to do that would be:
mstest /testcontainer:Common.Tests.dll > result.txt 2>&1
that would redirect all output to the result.txt

You can assign the output to a variable and then use it however you wish, like just outputting it to screen...
$mstest = Invoke-Expression "mstest /testcontainer:Common.Tests.dll"
Write-Output $mstest

Related

Coderunner issues Mac

Please can anyone help me out code runner only shows the right output after running the python file.
For example
Here I used the option "run python file" in terminal and it worked
Then i ran it using coderunner extension and it works
But when i change the output and run it, it doesn't change
It only changes after i run it with python file. So I have to run it in terminal for the right output to show. code runner only mirrors the last output in terminal
This may seem obvious but in the third picture, as you can see from the white circle on the tab where the x to close usually resides indicates that you have not saved the file hence it will output results from the last time you ran it using the 'run python file'. The 'run python file' button saves before running automatically so it would be easy to accidently miss the cause as now its saved with the new input and your code runner will output the new result again making it seem as though its duplicating the 'run python file' button.

MSBuild weird behavior when run inside a script

I have some PS scripts that I use for SVN tagging / releasing applications.
Usually its working fine, everything is built as I want to.
Few days ago, I'm told to make a fresh release of some older application.
So I tried leveraging my scripts for that purpose. So far so good.
The problem I'm facing now: Somehow, when MSBuild is called inside my script, its giving me errors
The thing is, when I execute the same command outside the script in a PS console, its building without errors.
The call: C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\MSBuild\Current\Bin\msbuild.exe solution.sln /t:Build /p:Configuration=Release /m /v:q /clp:Summary /nologo
Any suggestions are appreciated.
Apparently it has to do with PackageReference on older projects..
https://github.com/dotnet/sdk/issues/8100 my workaround is to build in VS first then use my script without restore or clean.
So I got my release.

Output is shown on Terminal instead of Output section in VS Code

As you can see, there is no output shown in output section. But the output is shown in terminal tab. Can someone help me in getting the output in output tab instead of Terminal tab ?
that is because you used the code runner extension, am i right? It runs the code by using the command prompt or terminal and run the code with the directory to your file. So if you use code runner extension, it will run the code in the terminal because it uses the terminal.
Your code is indeed supposed to be run from the terminal because you used the code-runner extension. Even though you used another method like running the code from python, it will still be running from the terminal.
Put the following in your settings.json file:
"code-runner.runInTerminal" : true
Courtesy of Code Runner in VSCode is running in output instead of CMD in the Terminal (the opposite question).

CodeAnalysis using msbuild does not fail on warning/error

I started down this path of wanting to do code analysis on my solution using msbuild. I was looking at FxCop but it appears to now be part of Visual Studio and from my understanding you need Visual Studio installed on your build agents.
I am calling msbuild from a powershell using the following command;
"$(get-content env:systemroot)\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe /tv:4.0 /p:RunCodeAnalysis=Always"
It appears to run the code analysis and output warnings but never fails the build, even after I added <CodeAnalysisTreatWarningsAsErrors>true</CodeAnalysisTreatWarningsAsErrors>
to my .csproj file.
All I want is to run code analysis from msbuild command line and have it fail the build if any warning is found. I understand it can be done in Visual Studio but I need to be able to run this from the command line (with/without VS2013)
Am I missing something? Shouldn't /p:RunCodeAnalysis=Always and setting the CodeAnalysisTreatWarningsAsErrors to true be all that is needed?

How to ensure vsvars32.bat has run

I have a build process using MSVC 2005. It only works correctly if run from a Visual Studio command prompt, not from a regular command prompt, because of the additional variables that get set. It's far too easy to run the wrong type of prompt and then get obscure error messages, so I'm trying to avoid this. I don't want to change my regular command prompt to always call vsvars32.bat, since I don't always want this, but I wanted to add a message to suggest using the Visual Studio Command Prompt. To do this, I wrote a BAT file
if "%VSINSTALLDIR%" == "" echo Did you want a Visual Studio Command Prompt?
However, this also shows up in the Visual Studio Command Prompt because it gets called before vsvars32.bat does.
Does any one have any idea how I could get a message added to a normal command prompt but not the Visual Studio 2005 Command Prompt? I suspect from how the Visual Studio Command Prompt is set up this isn't possible.
Thanks.
Why not execute vsvars32.bat from within your build process? The other option is to explicitly spawn a shell using something like cmd.exe /k path-to-vs\vsvars.bat - IIRC, the /k option makes the shell execute the argument and remain open.