We Keep Coding

Unable to run C# test unit project using batch command from jenkins

I am doing automation using selenium and c#. Everything is running file when I run from visual studio but getting issue in file path then run via jenkins.
Batch command I am trying :
"nuget.exe" restore UnitTestProject1.sln
"C:\Windows\Microsoft.NET\Framework64\v4.0.30319\MSBuild.exe" UnitTestProject1.sln
"C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE\MSTest.exe" /testcontainer:UnitTestProject1\bin\Debug\UnitTestProject1.dll
Output from Jenkins :
Building in workspace C:\Users\developer\.jenkins\workspace\LinkedinAutomation\UnitTestProject1
[UnitTestProject1] $ cmd /c call C:\Users\developer\AppData\Local\Temp\jenkins934555759751738078.bat
C:\Users\developer\.jenkins\workspace\LinkedinAutomation\UnitTestProject1>"nuget.exe" restore UnitTestProject1.sln
MSBuild auto-detection: using msbuild version '15.5.180.51428' from 'C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\15.0\bin'.
All packages listed in packages.config are already installed.
C:\Users\developer\.jenkins\workspace\LinkedinAutomation\UnitTestProject1>"C:\Windows\Microsoft.NET\Framework64\v4.0.30319\MSBuild.exe" UnitTestProject1.sln
Microsoft (R) Build Engine version 4.6.1055.0
[Microsoft .NET Framework, version 4.0.30319.42000]
Copyright (C) Microsoft Corporation. All rights reserved.
Building the projects in this solution one at a time. To enable parallel build, please add the "/m" switch.
Build started 3/5/2018 6:38:36 PM.
Project "C:\Users\developer\.jenkins\workspace\LinkedinAutomation\UnitTestProject1\UnitTestProject1.sln" on node 1 (default targets).
ValidateSolutionConfiguration:
Building solution configuration "Debug|Any CPU".
Project "C:\Users\developer\.jenkins\workspace\LinkedinAutomation\UnitTestProject1\UnitTestProject1.sln" (1) is building "C:\Users\developer\.jenkins\workspace\LinkedinAutomation\UnitTestProject1\UnitTestProject1\UnitTestProject1.csproj" (2) on node 1 (default targets).
Project file contains ToolsVersion="15.0". This toolset may be unknown or missing, in which case you may be able to resolve this by installing the appropriate version of MSBuild, or the build may have been forced to a particular ToolsVersion for policy reasons. Treating the project as if it had ToolsVersion="4.0". For more information, please see http://go.microsoft.com/fwlink/?LinkId=291333.
GenerateTargetFrameworkMonikerAttribute:
Skipping target "GenerateTargetFrameworkMonikerAttribute" because all output files are up-to-date with respect to the input files.
CoreCompile:
Skipping target "CoreCompile" because all output files are up-to-date with respect to the input files.
_CopyOutOfDateSourceItemsToOutputDirectory:
Skipping target "_CopyOutOfDateSourceItemsToOutputDirectory" because all output files are up-to-date with respect to the input files.
_CopyAppConfigFile:
Skipping target "_CopyAppConfigFile" because all output files are up-to-date with respect to the input files.
CopyFilesToOutputDirectory:
UnitTestProject1 -> C:\Users\developer\.jenkins\workspace\LinkedinAutomation\UnitTestProject1\UnitTestProject1\bin\Debug\UnitTestProject1.dll
Done Building Project "C:\Users\developer\.jenkins\workspace\LinkedinAutomation\UnitTestProject1\UnitTestProject1\UnitTestProject1.csproj" (default targets).
Done Building Project "C:\Users\developer\.jenkins\workspace\LinkedinAutomation\UnitTestProject1\UnitTestProject1.sln" (default targets).
Build succeeded.
0 Warning(s)
0 Error(s)
Time Elapsed 00:00:01.03
C:\Users\developer\.jenkins\workspace\LinkedinAutomation\UnitTestProject1>"C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE\MSTest.exe"
Microsoft (R) Test Execution Command Line Tool Version 15.0.27019.1
Copyright (c) Microsoft Corporation. All rights reserved.
Please specify tests to run, or specify the /publish switch to publish results.
For switch syntax, type "MSTest /help"
C:\Users\developer\.jenkins\workspace\LinkedinAutomation\UnitTestProject1>/testcontainer:UnitTestProject1.dll
The filename, directory name, or volume label syntax is incorrect.
C:\Users\developer\.jenkins\workspace\LinkedinAutomation\UnitTestProject1>exit 123
Build step 'Execute Windows batch command' marked build as failure
Finished: FAILURE
It seems everything is fine till end. It has issue in finding project dll file at end with test container.

I have the following set as a Windows Batch command:
. This is one long line that runs the individual project Test DLLs of our components. Each DLL is from a Unit Test Project.
It appears that your command line has forward slashes, and not the Windows directory separator, the backslash.
I have also found that I needed a different command line to get my tests running properly. I had to use the vstest.console.exe to run the tests.
"C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE\CommonExtensions\Microsoft\TestWindow\vstest.console.exe" Application_Tests\bin\Release\Application_Tests.dll AppLib_Tests\bin\Release\AppLib_Tests.dll
For the full command line: vstest.console.exe command line

MSBuild Exec - All commands exit with MSB3073, exit code 0xC0000005

Windows 10 64-bit - Visual Studio Community 2017
Brand new Hello World C# project.
I added the following to my build tasks:
<Target Name="AfterBuild">
<Message Text="Testing" Importance="high"></Message>
<Exec Command="echo Test" />
</Target>
I see the "Testing" Message executed by the build, so I know the Target is running, at least.
The next task, Exec, always shows the following no matter what commands I give it.
1>$(ProjectPath)(60,5): error MSB3073: The command "echo Test" exited with code -1073741819.
-1073741819 is of course 0xC0000005, Access Violation.
Note: The exact same thing happens if I don't use a Target but instead use post-build commands from the Project Properties GUI (It uses Exec to run those internally, anyway).
Note: I've had similar issues with VS Code somehow misusing my ComSpec variable, which for reference is defined as ComSpec : %SystemRoot%\system32\cmd.exe

MSBuild fails for solution with project dependencies

The build for my solution, which contains multiple projects, suddenly appears to be broken and the cause of the issue isn't clear. All of the projects in the solution target the same framework (4.5.1), however, some of the projects' dependencies might be targeting an earlier version of the framework. As of last week, we were able to successfully build solutions that fall under this scenario. Starting last Thursday, the builds appear to be broken without any changes to the build server or the solution.
To illustrate and remove some of the complexities with our production setup, I created a sample solution which mimics the behavior.
Project structure:
CBI Solution
CBI website
CBI Implementation Library
CBI Core library, defining the interfaces
Target Framework Version for the website and class libraries is 4.5.1
Replication Steps
Solution 1
Github repo: https://github.com/NikitaGolovko/Solution1.git
Build, using MSBuild 14. My command is:
msbuild.exe "%SOLUTION1PATH%\CBILite.sln" /p:platform="Any CPU" /p:configuration="Release" /v:d
Output
C:\Windows\Microsoft.NET\Framework\v4.0.30319\aspnet_compiler.exe -v /localhost_61806 -p cbi\ -u -f PrecompiledWeb\lo
calhost_61806\
Microsoft (R) ASP.NET Compilation Tool version 4.7.2046.0
Utility to precompile an ASP.NET application
Copyright (C) Microsoft Corporation. All rights reserved.
Done executing task "AspNetCompiler".
Task "Message" skipped, due to false condition; (!((false) or ('$(AspNetConfiguration)' == 'Debug') or ('$(AspNetConfig
uration)' == 'Release'))) was evaluated as (!((false) or ('Release' == 'Debug') or ('Release' == 'Release'))).
Done building target "Build" in project "cbi.metaproj".
Done Building Project "D:\Work\DotNet\Nikita\Solution1\cbi.metaproj" (default targets).
Done executing task "MSBuild".
Done building target "Build" in project "CBILite.sln".
Done Building Project "D:\Work\DotNet\Nikita\Solution1\CBILite.sln" (default targets).
Build succeeded.
0 Warning(s)
0 Error(s)
Time Elapsed 00:00:03.10
Full output is located here: https://github.com/NikitaGolovko/Solution1/blob/master/MSBuild_Output.txt
Solution 2
Github Repo: https://github.com/NikitaGolovko/Solution2.git
The solution is nearly identical to the Solution1, with the only exception being a dependency for Unity in CBI Implementation library. To simplify the process and eliminate the nuget restore step, I have included nuget packages with the solution.
Build, using MSBuild 14. My command is:
msbuild.exe "%SOLUTION2PATH%\CBILite.sln" /p:platform="Any CPU" /p:configuration="Release" /v:d
Output
C:\Windows\Microsoft.NET\Framework\v4.0.30319\aspnet_compiler.exe -v /localhost_61806 -p cbi\ -u -f PrecompiledWeb\lo
calhost_61806\
Microsoft (R) ASP.NET Compilation Tool version 4.7.2046.0
Utility to precompile an ASP.NET application
Copyright (C) Microsoft Corporation. All rights reserved.
D:\Work\DotNet\Nikita\Solution2\cbi\Index.aspx.vb(5): error BC30002: Type 'CBILite.Calculator' is not defined. [D:\Work
\DotNet\Nikita\Solution2\cbi.metaproj]
The command exited with code 1.
Done executing task "AspNetCompiler" -- FAILED.
Done building target "Build" in project "cbi.metaproj" -- FAILED.
Done Building Project "D:\Work\DotNet\Nikita\Solution2\cbi.metaproj" (default targets) -- FAILED.
Done executing task "MSBuild" -- FAILED.
Done building target "Build" in project "CBILite.sln" -- FAILED.
Done Building Project "D:\Work\DotNet\Nikita\Solution2\CBILite.sln" (default targets) -- FAILED.
Build FAILED.
Full output is located here: https://github.com/NikitaGolovko/Solution2/blob/master/MSBuild_Output.txt
Observations
Bin folder
When looking in the bin folder of the website, I notice that CBILite.dll is missing after the build for Solution2, but present in Solution1.
TargetFrameworkVersion
Passing TargetFrameworkVersion in the MSBuild arguments does not appear to influence the build. I have attempted to pass 4.5, 4.5.1 to no avail. HOWEVER passing 3.5 results in the successful build. This is extremely strange.
Metaproj
When comparing Metaproj files generated for both solutions, the only observable and seemingly important difference is the lack of the TargetFrameworkVersion element. Solution1 (without dependencies), contains v.4.0 element. Solution2 (with the dependency) does not.
I didn't include metaproj files in the repo but can share them if needed.
Visual Studio
Building the solution in Visual Studio works just fine.
Additional thoughts
The issue manifested itself rather suddenly and seems to be affecting most of our solutions that have mixed projects (C#/VB + website). Web Projects continue to function normally.
I've attempted to use MSBuild 15, but it resulted in the same behavior.
There are a few workarounds
Retaining the metaproj file with the solution and modifying it manually by adding v4.5.1 element.
Adding an additional build step to manually copy CBILib.dll into the website project (via the batch file or other means).
Adding a refresh file for the website pointing to CBILib/bin/Release folder
While all of these solutions might work, they're certainly hacks and will present problems in the future.
I'm hoping someone else has a better suggestion on how to handle this.

Make sure you have installed the following NuGet packages:
Microsoft.NET.Test.Sdk
MSTest.TestAdapter
MSTest.TestFramework
Microsoft.NETCore.App (if you use .NET Core)

build .net application in Jenkins using MSBuild

I have a .net application built on .net framework 3.5, I am trying to build this application on Jenkins CI server. I've added MSBuild plugin and and have added path to the .exe file of 2.0, 3.5 and 4.0 versions of MSBuild. But my building processes are failing by showing the below error message.
Path To MSBuild.exe: msbuild.exe
Executing command: cmd.exe /C msbuild.exe Neo.sln && exit %%ERRORLEVEL%%
[Test project] $ cmd.exe /C msbuild.exe Neo.sln && exit %%ERRORLEVEL%%
'msbuild.exe' is not recognized as an internal or external command,
operable program or batch file.
Build step 'Build a Visual Studio project or solution using MSBuild.' marked uild as failure
Finished: FAILURE
Could anyone plz help me out..??

To make the MSBuild plugin work, you need to configure the plugin in the Jenkins management screen.
NOTE: in the newer Jenkins versions you find the MSBuild configuration in the Global Tool Configuration:
Note the "Name" field, where I've called this particular configuration v4.0.30319. You could call it anything you like, but ideally the name will somehow refer to the version.
You'll need to refer to this name later in the Jenkins PROJECT that's failing.
Note: The yellow warning implies that the Path to MSBuild field should be populated with a directory name rather than a file name. In practice you do need to enter the filename here too (ie. msbuild.exe) or the build step will fail.
In the Jenkins project that's failing, go to the MSBuild build step.
The first field in the build step is "MSBuild Version". If you created the build step before configuring any MSBuild versions, the value here will be (default).
After configuring one or more MSBuild versions, the drop down will be populated with the available configurations. Select the one you require.
You can see here that I've now selected the named configuration that matches the installation above.

Jenkins | Manage Jenkins | Configure System
scroll down to the MSBuild section and click MSBuild installations
define the full path to msbuild.exe, on my system I have 3.5 and v4.0.30319
Note - specify the path to 32-bit tools even on a 64-bit system, otherwise you might get an error message:
Building Windows Phone application using MSBuild 64 bit is not supported.
So in Jenkins - it could be for example:
Name: Version 3.5
Path: C:\Windows\Microsoft.NET\Framework\v3.5\MSBuild.exe
Name: Version 4.0
Path: C:\Windows\Microsoft.NET\Framework\v4.0.30319\MSbuild.exe

I think you should set an absolute path for "msbuild.exe" in your Jenkins configuration,
for example:
C:\Windows\Microsoft.NET\Framework\v3.5\msbuild.exe

You can also add the path where the msbuild.exe is, to the PATH system environment variable of the node (or nodes) that is running that specific job.

You could try executing the
%comspec% /k ""c:\Program Files\Microsoft Visual Studio 10.0\VC\vcvarsall.bat"" x86
command, which will temporarily update your environment path variables to reflect the VS2010 build environment. Execute this before you call MSBUILD and see what happens. I use this in my own build scripts with no issues.
Side note; it's very likely counterproductive to have multiple versions of MSBUILD on your PATH. Concentrate on getting one version working and go from there.

sgen.exe x64 .net c# fails with "assembly with an incorrect format"

I have ws2008 x64 with vs2008.
When I set my vs to x64 (because I have 64bit dlls) and run compilation sgen says that
An attempt was made to load an assembly with an incorrect format
VS takse sgen from
C:\Program Files\Microsoft SDKs\Windows\v6.0A\bin\
and I think that it should take it from
C:\Program Files\Microsoft SDKs\Windows\v6.0A\bin\x64\
when i take 64bit version of sgen and put it into C:\Program Files\Microsoft SDKs\Windows\v6.0A\bin\ (replace 32bit version). I was able to compile.
What should I do to point to the correct version of sgen under vs.
Can I somehow configure solutinon platforms for one project to point to the correct sgens (for x86 to 32 bit and for x64 to 64 bit sgen version)?

Does this help you out? Take a look at the section where he uses sgen as a post build:
As a consequence you need to add the SGen command as a custom post-build event on the Build Events tab of your VS project properties:
"C:\Program Files\Microsoft Visual Studio 8\SDK\v2.0\Bin\sgen.exe" /force /assembly:"$(TargetPath)" /compiler:/keycontainer:VS_KEY_5EFB7881D71082EDCF85DBBFCD748B9A /compiler:/delaysign-

This is the best answer I could find: Conditional Post-Build Event Command for x64 sgen, a blog post by Michael Hanes.
Use a post build event, that conditionally checks if the 64 bit SGEN is installed, and use it when needed:
REM Use the 64-bit sgen from the Win 2008 and
REM .NET 3.5 SDK in a 64-bit dev environment
REM ProgramFiles variable is set to
REM 'Program Files (x86)' in a x64 environment
REM Processor_Architecture variable returns x86
REM in both an x86 and x64 environment within VS.
if /I "%ProgramFiles%" == "C:\Program Files" (
set SgenToolPath="C:\Program Files\Microsoft
SDKs\Windows\v6.0A\Bin\sgen.exe"
) else (
set SgenToolPath="C:\Program Files\Microsoft
SDKs\Windows\v6.1\Bin\x64\sgen.exe"
)
%SgenToolPath% /compiler:"\"/keyfile:$(ProjectDir)
MyKeyFile.snk"\" /force "$(TargetPath)"
This is intended to be a replacement for the "Generate Serialization Assemblies" dropdown setting for "On" for a given Visual Studio project.

Add a little pre-build action just to dump out env vars that are in effect at build time.
Check vcvarsall.bat and follow it as it loads other bat-s for different host/build platform combos.
Check actual bitness of devenv process (say with process explorer).

There's a different solution posted on this blog post about specifying __SdkSgenTool conditionally:
The only missing thing is that I do need to set SGenToolPath to my build output directory. This was harder as expected since as a normal property it was overwritten by other MsBuild tasks. The solution that finally did work was to create the already existing property and set the value to its final value when no other tasks could interfere.
Below is the “code” to make Sgen work in 64 bit. You need to define the __SdkSgenTool variable in all build modes since the post build steps like copy are executed regardless of the build mode.
<PropertyGroup Condition="'$(Configuration)|$(Platform)' == 'Release|x64'">
....
<GenerateSerializationAssemblies>On</GenerateSerializationAssemblies>
<SGenUseProxyTypes>false</SGenUseProxyTypes>
<__SdkSgenTool Condition="exists('C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bin\NETFX 4.0 Tools\x64\sgen.exe')">C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bin\NETFX 4.0 Tools\x64\sgen.exe</__SdkSgenTool>
<__SdkSgenTool Condition="exists('C:\Program Files\Microsoft SDKs\Windows\v7.0A\Bin\NETFX 4.0 Tools\x64\sgen.exe')">C:\Program Files\Microsoft SDKs\Windows\v7.0A\Bin\NETFX 4.0 Tools\x64\sgen.exe</__SdkSgenTool>
</PropertyGroup>
...
<Import Project="$(MSBuildToolsPath)\Microsoft.CSharp.targets" />
<Target Name="BeforeBuild">
<Copy SourceFiles="$(__SdkSgenTool)" DestinationFiles="$(TargetDir)\sgen.exe" SkipUnchangedFiles="true" />
<CreateProperty Value="$(TargetDir)">
<Output TaskParameter="Value" PropertyName="SGenToolPath" />
</CreateProperty>
I have heard that this issue will be fixed with VS2012 which is a good
thing.
This doesn't appear to be fixed in VS2012. I would use this with caution, because __SdkSgenTool appears to be an internal property, and therefore not something you can rely on.