Enable more tests on CI #332
Conversation
|
seems ok to me. dunno why fsharp.core doesnt resolve from GAC in mono, but who care atm, is ok with |
baronfel
force-pushed
the
enable_more_tests
branch
from
679ae26
to
4a7d0f0
Compare
|
@baronfel i think some errors are because MSbuild 12 is not installed in appveyor. |
|
Looks like on appveyor we need to add fsharp.core and system.io references to a few old-style project files, and on linux we've got much larger problems: those aren't even in json blobs, those are coming from the background file parser if I'm reading this right |
- reenable outputcache and invalidprojectfile testscases - update the output.json for each of these cases was consistent with a) the changed stacktraces of the ProjectCrackerTool and b) the 'quitting...' info message - fix regexes that were over-escaping the groups/characters at the end - readd the linter test exceptions - update errors test project file to version 15 - add system.runtime reference - strip packagesdir paths reenable tests: - finddeclarations - multiproj - multiunsaved - paramcompletion - projectreload - robustcommands - symboluse - test1json - nofsharpcore - uncompiledreferencedprojects adjust baselines: - for new information coming back from symboluse - because there's a file parse notification now update expected message from CI run
that's require to install MSBuild v12 assemblies in GAC, needed by FCS
enricosada
force-pushed
the
enable_more_tests
branch
from
ac6139f
to
a788ee4
Compare
|
@baronfel i rebased and squashed the commits. i fixed the projects, in win should be ok. the @baronfel i'll check ci for travis |
|
Nice detective work! |
must specify the target framework, otherwise is v4.0 by default. the project wasnt building either (`msbuild /t:Build`) with warning ``` C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\15.0\bin\Microsoft.Common.CurrentVersion.targe ts(2106,5): warning MSB3274: The primary reference "FSharp.Core" could not be resolved because it was built against the ".NETFramework,Version=v4.5" framework. This is a higher version than the currently targeted framework ".NETFramework, Version=v4.0". [e:\github\fsharp\FsAutoComplete\test\FsAutoComplete.IntegrationTests\ErrorTestsJson\Test1.fsproj] C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\15.0\bin\Microsoft.Common.CurrentVersion.targe ts(2106,5): warning MSB3267: The primary reference "System.IO", which is a framework assembly, could not be resolved in the currently targeted framework. ".NETFramework,Version=v4.0". To resolve this problem, either remove the reference " System.IO" or retarget your application to a framework version which contains "System.IO". [e:\github\fsharp\FsAutoComp lete\test\FsAutoComplete.IntegrationTests\ErrorTestsJson\Test1.fsproj] ``` remove useless `System.Runtime` to minimize changes
enricosada
force-pushed
the
enable_more_tests
branch
from
a788ee4
to
0d89136
Compare
|
appveyor is now green. the travis error is strange, i'll print the expection message too. |
|
ok, on mono a Dunno if that's because is not killed fast enough or another reason, but can be ignored i think |
|
It looks like the base error message coming back from MSBuild is being normalized in different ways on windows and *nix. |
|
Yeah it looks like on mono now we'll need to strip off the |
|
saved: different: differences I see:
|
|
yes. i'll disable for now on mono. |
|
tracking the normalization issues in #339 |
|
naa, it doesnt matter that much. tests like that are few. the text can be normalized or the message rewritten, and will be ok. |
|
The test failure now is coming from the project type parsing, which is reading from a streamreader. Somehow the streamreader line is null? That's weird. |
|
Green! |
|
Fix it, one commit at time. Awesome work @baronfel |
This PR enables a few tests what were blocked off, as well as converting the msbuild-4 tests to use toolsversion 15 and adding in explicit fsharp.core and system.runtime references as appropriate (ie. when the test wasn't explicitly testing a missing fsharp.core reference).
This is currently failing across most of the cloud providers, but I wanted to open it up as a base for discussion and ensure that I was thinking about things the correct way.