I've configured my .testsettings file as per instructions to run Hosts in 64bit.
But I don't see anything actually written to the settings file.
<?xml version="1.0" encoding="UTF-8"?>
<TestSettings name="accounting" id="907240cb-5a90-45f4-a41f-2e73533c8c25" xmlns="http://microsoft.com/schemas/VisualStudio/TeamTest/2010">
<Description>These are default test settings for a local test run.</Description>
<Deployment enabled="false" />
<Execution>
<Timeouts runTimeout="1800000" testTimeout="40000" />
<TestTypeSpecific>
<UnitTestRunConfig testTypeId="13cdc9d9-ddb5-4fa4-a97d-d965ccfc6d4b">
<AssemblyResolution>
<TestDirectory useLoadContext="true" />
</AssemblyResolution>
</UnitTestRunConfig>
</TestTypeSpecific>
<AgentRule name="LocalMachineDefaultRole">
</AgentRule>
</Execution>
<Properties />
</TestSettings>
And so my build server (Teamcity) continues to build in 32bit.
i've also tried setting it in VS but that definitely doesn't get persisted anywhere for Teamcity to know
how do i force Teamcity to use 64bit ?
Related
Has anybody successfully implemented Oracle tracing with ODP.NET (Managed version) from within a Powershell script? The ODP.NET calls work in Powershell as expected, but it is not apparent that the config file is being read to set the tracing level and trace file destination, despite following the directions and placing app.config in the Powershell home directory.
app.config
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<oracle.manageddataaccess.client>
<version number="*">
<settings>
<!-- #OracleConfiguration.TraceFileLocation =".\traces";
#OracleConfiguration.TraceLevel = 7; -->
<setting name=”TraceLevel” value=”7" />
<setting name=”TraceFileLocation” value=”.\traces\”/>
</settings>
</version>
</oracle.manageddataaccess.client>
</configuration>
This has always been squirrelly in Oracle anyway but seems to not work at all with Powershell...
I ended up taking some c# sample code to get trace of the connection.
Does this work though
How to add configuration options to ODP.Net Managed Driver in Powershell
I currently updated to visual studio 2017 enterprise edition version 15.9.24 .
The issue that i'm running across is i'm not able to debug my test using the
runsettings file. When I debug the test its access any dlls and deployed files from my TestResults Out folder instead of bin/debug folder since i'm in debug mode. When i was running Visual studio 2015 I was using .testsettings file
and was able to run my test from the bin/debug folder. Since .testsettings is
going to be deprecated i decided to move to runsettings.
Searching the web and stack someone stated that i needed to have the settings located in the runsettings file that is labeled DeploymentEnabled to false to achieve this. I did this and still getting error because the application is running and trying to access the files from my TestResults Out folder. I also changed the run settings to forced legacy mode to true and added directory of my old test settings file but still not working.
Is there another setting that i'm not taken into consideration
or am i missing something or is something wrong with my run settings.
Please see my example of my current runsettings file below
Thanks for any help or direction given.
<?xml version="1.0" encoding="utf-8"?>
<RunSettings>
<!-- Configurations that affect the Test Framework -->
<RunConfiguration>
<MaxCpuCount>1</MaxCpuCount>
<!-- Path relative to directory that contains .runsettings file
<ResultsDirectory>.\TestResults</ResultsDirectory> -->
<!-- x86 or x64 -->
<!-- You can also change it from the Test menu; choose "Processor Architecture for AnyCPU Projects" -->
<TargetPlatform>x86</TargetPlatform>
<!-- Framework35 | [Framework40] | Framework45 -->
<TargetFrameworkVersion>Framework45</TargetFrameworkVersion>
<!-- Path to Test Adapters -->
<!--<TestAdaptersPaths>%SystemDrive%\Temp\foo;%SystemDrive%\Temp\bar</TestAdaptersPaths>-->
<!-- TestSessionTimeout was introduced in Visual Studio 2017 version 15.5 -->
<!-- Specify timeout in milliseconds. A valid value should be greater than 0 -->
<TestSessionTimeout>15000000</TestSessionTimeout>
</RunConfiguration>
<!-- Configurations for data collectors -->
<DataCollectionRunSettings>
<DataCollectors>
<DataCollector friendlyName="Code Coverage" uri="datacollector://Microsoft/CodeCoverage/2.0" assemblyQualifiedName="Microsoft.VisualStudio.Coverage.DynamicCoverageDataCollector, Microsoft.VisualStudio.TraceCollector, Version=11.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a">
<Configuration>
<CodeCoverage>
<ModulePaths>
<Exclude>
<ModulePath>.*CPPUnitTestFramework.*</ModulePath>
</Exclude>
</ModulePaths>
<!-- We recommend you do not change the following values: -->
<UseVerifiableInstrumentation>True</UseVerifiableInstrumentation>
<AllowLowIntegrityProcesses>True</AllowLowIntegrityProcesses>
<CollectFromChildProcesses>True</CollectFromChildProcesses>
<CollectAspDotNet>False</CollectAspDotNet>
</CodeCoverage>
</Configuration>
</DataCollector>
</DataCollectors>
</DataCollectionRunSettings>
<!-- Parameters used by tests at run time -->
<TestRunParameters>
<Parameter name="webAppUrl" value="http://localhost" />
<Parameter name="xxxxUser" value="xxxxm,xxxxtAuto01,xxxxtAuto02,xxxxxtAuto03,xxxxtAuto04" />
<Parameter name="xxxxxxxxxnbr" value="xx86,xx90,xx91,xx92,xx93" />
</TestRunParameters>
<!-- MSTest adapter -->
<MSTest>
<MapInconclusiveToFailed>true</MapInconclusiveToFailed>
<CaptureTraceOutput>false</CaptureTraceOutput>
<DeleteDeploymentDirectoryAfterTestRunIsComplete>true</DeleteDeploymentDirectoryAfterTestRunIsComplete>
<DeploymentEnabled>false</DeploymentEnabled>
<!---->
<ForcedLegacyMode>true</ForcedLegacyMode>
<SettingsFile>%xxxx_Automation_Test\xxxx_Automation_Test\xxx_Automation_Test\xxxxAutomation.testsettings;</SettingsFile>
<InProcMode>true</InProcMode>
<KeepExecutorAliveAfterLegacyRun>False</KeepExecutorAliveAfterLegacyRun>
<AssemblyResolution>
<!--
<Directory path="C:\xxx_Automation\xxxx_Automation_Test\xxx_Automation_Test\bin\" includeSubDirectories="false"/>-->
</AssemblyResolution>
</MSTest>
</RunSettings>
I updated my runsettings to have the file name of of run settings and to
update the ForcedLegacyMode to true.
<ForcedLegacyMode>true</ForcedLegacyMode>
<SettingsFile>xxxxxAutomation.testsettings</SettingsFile>
<KeepExecutorAliveAfterLegacyRun>False</KeepExecutorAliveAfterLegacyRun>
<AssemblyResolution>
I am following Code Coverage Results Import (C#, VB.NET) documentation for SonarQube.
For my project, I am able to generate test coverage binary file as "SonarQubeTests.csproj.coverage"
Visual Studio can open this file with no problem. I can see all the details.
Then when I try to generate ".coveragexml" file with following command;
"C:\Program Files (x86)\Microsoft Visual Studio 14.0\Team Tools\Dynamic Code Coverage Tools\CodeCoverage.exe" "analyze /output:C:\SonarQubeTests.csproj.coveragexml C:\SonarQubeTests.csproj.coverage"
It does generate ".coveragexml" file, but when I try to open Visual Studio it gives me following error:
I can open this file with text editor and content seems all fine. But neither Visual Studio 2015 nor sonarqube does not read this file.
What I am missing here?
P.S I have also runner settings for Ms Test runner as below.
Not sure if this will effect something;
<?xml version="1.0" encoding="utf-8"?>
<RunSettings>
<!-- Configurations that affect the Test Framework -->
<RunConfiguration>
<MaxCpuCount>1</MaxCpuCount>
<!-- Path relative to solution directory -->
<ResultsDirectory>C:\</ResultsDirectory>
<!-- [x86] | x64
- You can also change it from menu Test, Test Settings, Default Processor Architecture -->
<TargetPlatform>x86</TargetPlatform>
<!-- Framework35 | [Framework40] | Framework45 -->
<TargetFrameworkVersion>Framework45</TargetFrameworkVersion>
<!-- Path to Test Adapters -->
<TestAdaptersPaths>%SystemDrive%\Temp\foo;%SystemDrive%\Temp\bar</TestAdaptersPaths>
</RunConfiguration>
<!-- Configurations for data collectors -->
<DataCollectionRunSettings>
<DataCollectors>
<DataCollector friendlyName="Code Coverage" uri="datacollector://Microsoft/CodeCoverage/2.0" assemblyQualifiedName="Microsoft.VisualStudio.Coverage.DynamicCoverageDataCollector, Microsoft.VisualStudio.TraceCollector, Version=11.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a">
<Configuration>
<CodeCoverage>
<ModulePaths>
<Exclude>
<ModulePath>.*CPPUnitTestFramework.*</ModulePath>
</Exclude>
</ModulePaths>
<!-- We recommend you do not change the following values: -->
<UseVerifiableInstrumentation>True</UseVerifiableInstrumentation>
<AllowLowIntegrityProcesses>True</AllowLowIntegrityProcesses>
<CollectFromChildProcesses>True</CollectFromChildProcesses>
<CollectAspDotNet>False</CollectAspDotNet>
</CodeCoverage>
</Configuration>
</DataCollector>
</DataCollectors>
</DataCollectionRunSettings>
<!-- Parameters used by tests at runtime -->
<TestRunParameters>
<Parameter name="webAppUrl" value="http://localhost" />
<Parameter name="webAppUserName" value="Admin" />
<Parameter name="webAppPassword" value="Password" />
</TestRunParameters>
<!-- Adapter Specific sections -->
<!-- MSTest adapter -->
<MSTest>
<MapInconclusiveToFailed>True</MapInconclusiveToFailed>
<CaptureTraceOutput>false</CaptureTraceOutput>
<DeleteDeploymentDirectoryAfterTestRunIsComplete>False</DeleteDeploymentDirectoryAfterTestRunIsComplete>
<DeploymentEnabled>False</DeploymentEnabled>
<AssemblyResolution>
<Directory Path="D:\myfolder\bin\" includeSubDirectories="false"/>
</AssemblyResolution>
</MSTest>
</RunSettings>
I think you could use vstest.console to get code coverage directly. We do not sure whether VS could open the code coverage that generated by third party tools.
I think if we could vstest.console to get the code coverage will has not problems. please try it to see the results.
I have a web project and I craeted a Test publish configuration. I use Web Deploy Package for publish method. My target is to have a replacable parameter for a setting in appSettings, so that on deployment a new setting value would be used in SetParameters.xml. I use parameters.xml file created in the root project folder with the following structure.
parameters.config
<parameters>
<parameter name="webApiUrl"
defaultValue="http://localhost:50594/">
<parameterEntry
kind="XmlFile"
scope="Web.config"
match="/configuration/appSettings/add[#key='webApiUrl']/#value" />
</parameter>
</parameters>
Web.config
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<appSettings>
<add key="webApiUrl" value="http://localhost:50594/" />
</appSettings>
</configuration>
The problem is that when the project is published the webApiUrl setting is not changed to $(ReplacableToken_webApiUrl) so when the project is deployed the value in SetParameters.xml is not taken into consideration.
I used a lot of different variations of scope and match, but non of them worked.
scope="\Web.config$", "obj\x86\Test\Package\PackageTmp\Web.config$", "\Web.config$", "\web.config$"
When I publish the project I check the folder (ProjectRoot)\obj\x86\Test\Package\PackageTmp\Web.config to see if the parametrization works.
Background
I'm putting together a Continuous Integration system at work on two VMs running on my local desktop. VM #1 (Toolbox) is running CruiseControl.Net, Subversion, BugTracker.Net and SQL Server Express. VM #2 (BuildMaster) is running NAnt with NAntContrib and has VB 6.0 and the 1.0/1.1/2.0/3.5 .Net Framework SDKs installed. The intent is to tightly control what's installed on BuildMaster and be much looser on Toolbox and developer workstations.
Issue
I had a CCNet project on Toolbox that successfully compiled a test VB 6.0 application on BuildMaster, but the build started failing last week. The only thing I remember doing was install BugTracker.Net and SQL Server Express on Toolbox.
Symptoms
The build fails and returns an exception:
<![CDATA[Starting 'vb6 ( /make "\\buildmaster\Working\TestApp\TestApp.vbp" /outdir "\\buildmaster\Working\TestApp\build" /out "\\buildmaster\Working\TestApp\TestApp.build.err")' in '\\buildmaster\Working\TestApp']]></message><duration>711.02240000000006</duration></task><duration>761.09440000000006</duration></target><failure><builderror><type>NAnt.Core.BuildException</type><message><![CDATA['vb6' failed to start.]]></message><location><filename>\\buildmaster\Working\TestApp\TestApp.build</filename><linenumber>39</linenumber><columnnumber>4</columnnumber></location><stacktrace><![CDATA[ at NAnt.Core.Tasks.ExternalProgramBase.StartProcess() in c:\Nant\src\NAnt.Core\Tasks\ExternalProgramBase.cs:line 501
at NAnt.Core.Tasks.ExternalProgramBase.ExecuteTask() in c:\Nant\src\NAnt.Core\Tasks\ExternalProgramBase.cs:line 386
at NAnt.Contrib.Tasks.Vb6Task.ExecuteTask() in c:\Nant\contrib\src\Tasks\Vb6Task.cs:line 220
at NAnt.Core.Task.Execute() in c:\Nant\src\NAnt.Core\Task.cs:line 186
at NAnt.Core.Target.Execute() in c:\Nant\src\NAnt.Core\Target.cs:line 247
at NAnt.Core.Project.Execute(String targetName, Boolean forceDependencies) in c:\Nant\src\NAnt.Core\Project.cs:line 910
at NAnt.Core.Project.Execute() in c:\Nant\src\NAnt.Core\Project.cs:line 862
at NAnt.Core.Project.Run() in c:\Nant\src\NAnt.Core\Project.cs:line 947]]></stacktrace><internalerror><type>System.ComponentModel.Win32Exception</type><message><![CDATA[The system cannot find the file specified]]></message><stacktrace><![CDATA[ at System.Diagnostics.Process.StartWithCreateProcess(ProcessStartInfo startInfo)
at System.Diagnostics.Process.Start()
at NAnt.Core.Tasks.ExternalProgramBase.StartProcess() in c:\Nant\src\NAnt.Core\Tasks\ExternalProgramBase.cs:line 498]]></stacktrace></internalerror></builderror></failure><duration>1211.7424</duration></buildresults>
Obviously, the meat of the exception is [CDATA['vb6' failed to start.]]. My problem is that when I run the Nant build directly on BuildMaster it completes the build successfully every time.
For the sake of completeness, here's my NAnt build script:
<?xml version="1.0" ?>
<project name="TestApp" default="build">
<!-- set build.date property to current date in format yyyy-MM-dd -->
<tstamp property="build.date" pattern="yyyy-MM-dd" />
<!-- global project settings -->
<property name="project.name" value="TestApp" />
<property name="project.version" value="1.00" unless="${property::exists('project.version')}" />
<property name="project.release.type" value="release" unless="${property::exists('project.release.type')}" /> <!-- nightly / dev / alpha / beta# / rc# / release -->
<property name="build.warnaserror" value="false" />
<!-- default configuration -->
<property name="project.client" value="" />
<property name="build.defines" value="" />
<property name="build.number" value="${math::abs(math::floor(timespan::get-total-days(datetime::now() - datetime::parse('01/01/2000'))))}" />
<!-- platform specific properties. These are the defaults -->
<property name="current.build.defines" value="${build.defines}" />
<!-- Build Tasks -->
<target name="init" description="Initializes build properties">
<property name="build.dir" value="${project::get-base-directory()}\build" />
<echo message="Build Directory is ${build.dir}" />
</target>
<target name="clean" depends="init" description="Deletes current build configuration">
<echo message="Clearing out files before recompiling..." />
<delete verbose="true">
<fileset basedir="${build.dir}">
<include name="TestApp*.exe" />
</fileset>
</delete>
</target>
<target name="build" depends="clean" description="Perform a build of the base TestApp product">
<mkdir dir="${build.dir}" unless="${directory::exists(build.dir)}" />
<!-- Actually compile VB6 project into executable -->
<vb6 project="TestApp.vbp" outdir="${build.dir}" errorfile="TestApp.build.err" verbose="true" />
</target>
</project>
Your help is greatly appreciated!
I might be misinterpreting your question so please bear with me. CCNet's nant task operatates on the local machine (the machine running CCNet).
If ToolBox is running CCNet but BuildMaster is running all tools (i.e. VB6, etc), I'm fairly sure there no way to do what's being attempted. Generally, CCNet needs to be running on the machine actually performing the builds. Therefore, the fact that VB6 cannot be found is because VB6 is not installed on ToolBox.
However, CCNet does have a way to monitor/control multiple build servers from one. So in your case you could configure ToolBox to control BuildMaster's builds, but CCNet would need to be installed on both. For a reference on something like this you can check out Splitting the build on CCNet's site.