Comments (9)
The latest release, 2.0.324 has the changes in the project files to build without having to clear %Platform%; and I've taken the results of working with just the x86 runtime (and not the SDK) on the AppVeyor default build machine, and written them up as a wiki page.
It boils down to -- if you can get your tests to run without the coverage gathering, then you're good. It is possible to inject either and x86 or an AnyCPU recording assembly into the system under test by pre-building altcover appropriately then running rather than as a build+run in one step; and whichever you've built should work to drive the coverage collection in runner mode.
from altcover.
Interesting. The failure
[00:03:53] C:\projects\advancedlsupport\altcover\altcover.1.6.230\tools\netcoreapp2.0\AltCover\Runner.fs(142,34): error FS0039: The value, constructor, namespace or type 'Base' is not defined. [C:\projects\advancedlsupport\altcover\altcover.1.6.230\tools\netcoreapp2.0\AltCover\altcover.core.fsproj]
says that it's failing to find code from a file that is shared and linked into the main program by relative path.
from altcover.
I've repro'd the problem, including the subsequent x86 image format issue; and clearing the platform (and letting it default to AnyCPU) is the best work-round for the moment.
from altcover.
Analysis:
Different bitness is a dimension that slipped through my test set.
- The shared code uses a compilation constant to distinguish between whether it's in the main program (CLR4 in the full framework) or the recorder assembly (CLR2, ditto); that constant is only set when Platform is AnyCPU. Fixing is trivial -- just hoist the constant out of the conditional PropertyGroup elements in the .fsproj file -- but is insufficient of itself.
- the 64-bit dotnet command will happily build x86 assemblies if directed through the environment variable "Platform" (though no documented command-line flag does this), but doesn't want to execute them,
dotnet run
protesting withSystem.BadImageFormatException
when you try. This seems to be the next issue that's been hit.
If the full framework is available, it would be worth trying the experiment of using the net45 version instead -- that is one of the test cases in the build, and it also with mono on Linux -- where at least you have known AnyCPU assemblies.
Meanwhile, I have a test matrix to draw up and fill in.
from altcover.
So I installed the x86 build of the .net core SDK 2.1.4; and while C:\Program Files (x86)\dotnet\
has been added to my PATH
, it's sandwiched in-between to instances of C:\Program Files\dotnet\
. This means that what gets defaulted by invoking just dotnet
is still the 64-bit version.
That means that even after I've fixed the compilation constant, running instrumentation with %Platform%
as "x86" still blows up with System.BadImageFormatException
. If I specifically invoke C:\Program Files (x86)\dotnet\dotnet.EXE
, however, the instrumentation step works.
from altcover.
As you suggested i tried specifically invoking the x86 dotnet.exe based on stored platform variable condition in this build
(here is related batch script)
:: Instrument the test assemblies
if "%TEMP_PLATFORM%"=="x86" (
"C:\Program Files (x86)\dotnet\dotnet.EXE" run^
--project altcover\altcover.1.6.230\tools\netcoreapp2.0\AltCover\altcover.core.fsproj --configuration %CONFIGURATION% --^
-i=AdvancedDLSupport.Tests\bin\%OUTPUT_DIR%\netcoreapp2.0 -o=instrumented-adl -x=coverage-adl.xml^
--assemblyExcludeFilter=.+\.Tests --assemblyExcludeFilter=AltCover.+ --assemblyExcludeFilter=Mono\.DllMap.+
"C:\Program Files (x86)\dotnet\dotnet.EXE" run^
--project altcover\altcover.1.6.230\tools\netcoreapp2.0\AltCover\altcover.core.fsproj --configuration %CONFIGURATION% --^
-i=Mono.DllMap.Tests\bin\%OUTPUT_DIR%\netcoreapp2.0 -o=instrumented-mdl -x=coverage-mdl.xml^
--assemblyExcludeFilter=.+\.Tests --assemblyExcludeFilter=AltCover.+
) else (
"C:\Program Files\dotnet\dotnet.EXE" run^
--project altcover\altcover.1.6.230\tools\netcoreapp2.0\AltCover\altcover.core.fsproj --configuration %CONFIGURATION% --^
-i=AdvancedDLSupport.Tests\bin\%OUTPUT_DIR%\netcoreapp2.0 -o=instrumented-adl -x=coverage-adl.xml^
--assemblyExcludeFilter=.+\.Tests --assemblyExcludeFilter=AltCover.+ --assemblyExcludeFilter=Mono\.DllMap.+
"C:\Program Files\dotnet\dotnet.EXE" run^
--project altcover\altcover.1.6.230\tools\netcoreapp2.0\AltCover\altcover.core.fsproj --configuration %CONFIGURATION% --^
-i=Mono.DllMap.Tests\bin\%OUTPUT_DIR%\netcoreapp2.0 -o=instrumented-mdl -x=coverage-mdl.xml^
--assemblyExcludeFilter=.+\.Tests --assemblyExcludeFilter=AltCover.+
)
but got a Did you mean to run dotnet SDK commands?
message.
Any insight into why that might be happening?
from altcover.
Sorry, you can disregard the last question. I wrongly assumed the build machine had the x86 dotnet sdk installed.
from altcover.
Assuming the thumbs-up and a quiet week means all is now good.
from altcover.
I believe so.
from altcover.
Related Issues (20)
- Microsoft.NET.Test.Sdk 17.8.0 support HOT 7
- [enhancement] integration with xharness and/or device runners for iOS and Android HOT 2
- `dotnet test /p:AltCover=true /p:AltCoverInPlace=true` results in System.IO.IOException: The process cannot access the file 'C:\src\testprj\bin\Debug\net8.0\AltCover.Recorder.g.dll' because it is being used by another process. HOT 5
- help with getting started HOT 2
- Path.GetFullPath no longer resolves long file paths HOT 7
- Could not find coverage.xml.zip when running Instrumented binaries HOT 5
- Adding AltCover to projects results in dotnet test running against all projects in solution HOT 6
- Running AltCover Runner in parallel mode HOT 2
- Question about cyclomatic complexity for pattern match HOT 2
- Changes so AltCover will run when FIPS compliance is required HOT 13
- .../Temp/tmp###.altcover.runsettings not found Intermittent tests ignored. HOT 2
- BranchPoints differ between .NET Framework and .NET 7 when using interpolated strings HOT 5
- Question Regarding assemblies being added to code coverage result HOT 2
- Command vstest.console.exe not started. Why? HOT 3
- altcover runner --OutputFile gives incorrect summary output HOT 8
- ERROR *** Instrumentation phase failed - Failed to resolve assembly: System.Data.Common HOT 8
- Generic methods share the same name and signature HOT 5
- Collection phase failed with an Error HOT 9
- Per-test level code coverage HOT 2
- Coverage collection requires instrumented code in same location until collection is not completed causing service downtime HOT 4
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from altcover.