PartCover 4.0 Only Reports NUnit Libraries - .net-4.0

I'm using PartCover 4.0 (from the sourceforge page, latest dev build) with NUnit 2.5.8 on Windows 7 (x64). PartCover runs ok (using the -x86.exe), but it only shows me coverage for various NUnit packages -- not my own source-code.
I originally didn't use CorFlags.exe since I didn't get the COM error; I tried it anyways, and it didn't make any difference.
I've looked at all the other questions on Stack Overflow, and none seem to apply; I'm using PartCover 4.0, there are no spaces in any of my names, my coverage rule is the most broad (+[*]*), and I've run CorFlags.exe.
What am I missing?

I had this problem yesterday and, searching for the answer, came across this unanswered question. Now that I've found the answer, at least for me, I thought I'd come and leave help for the next person to do the same.
It turned out to be as simple as NUnit-console.exe being configured to support .NET 2.0 rather than .NET 4.0. You can see this in a "Runtime Environment" section of the PartCover output.
In each of the config files in NUnit's bin\net-2.0 folder, add this section directly below the configuration tag
<startup>
<requiredRuntime version="v4.0.20506" />
</startup>

Related

What's the replacement for fuslogvw in .net core 2?

When encountering problems with resolving DLLs and assemblies in general with .Net fuslogvw gave you the ability to log the binding attempts so you could see exactly where it was looking and what was going on.
There is a github issue discussing this, but it's not exactly got very much detail on what COREHOST_TRACE actually provides, nor the best way to get the output, nor how to interpret the output.
So, is COREHOST_TRACE the best option?
If so how is it used?
If not, what's the better option?
I'd like to know the answer to this general question, because it's a useful tool to have and so has uses well beyond my current problem. However I am also trying to fix a specific problem, so I've included details of that below.
I'm using...
VS 15.7.2
asp.net core 2.0
The DLL in question is native, and is being accessed via DllImport.
Interestingly the DLL is resolved when I publish a release build, but fails running locally for development builds.
Exception: System.DllNotFoundException: Unable to load DLL 'libwkhtmltox': The specified module could not be found. (Exception from HRESULT: 0x8007007E)
The DLL in question is beinging copied to the root of the output directory:
<ItemGroup>
<ContentWithTargetPath Include="Dependencies\wkhtmltox\v0.12.4\32 bit\libwkhtmltox.dll">
<CopyToOutputDirectory>Always</CopyToOutputDirectory>
<TargetPath>libwkhtmltox.dll</TargetPath>
</ContentWithTargetPath>
</ItemGroup>
It's a long time since the original question, but as of .NET 5, there is dotnet trace. See https://learn.microsoft.com/en-us/dotnet/core/dependency-loading/collect-details.
(I found this via https://github.com/dotnet/runtime/issues/12506#issuecomment-895192112.)

only supports language versions up to Visual Basic 2012

[EDIT: It is a memory issue. The memory on my computer goes from 42% used to 91% in a few seconds just before this error. The error message about the compiler supporting up to 2012 is just a red-herring. That message is always output from the compiler. ]
I just converted a visual basic application from VS2005 to VS2017.
I get this error when I try to start it:
Server Error in '/' Application.
Compilation Error Description: An error occurred during the
compilation of a resource required to service this request. Please
review the following specific error details and modify your source
code appropriately.
Compiler Error Message: The compiler failed with error code
-2147024888.
Show Detailed Compiler Output:
C:\Program Files (x86)\IIS Express> Microsoft (R) Visual Basic
Compiler version 14.7.2556 for Visual Basic 2012 Copyright (c)
Microsoft Corporation. All rights reserved.
This compiler is provided as part of the Microsoft (R) .NET Framework,
but only supports language versions up to Visual Basic 2012, which is
no longer the latest version. For compilers that support newer
versions of the Visual Basic programming language, see
http://go.microsoft.com/fwlink/?LinkID=533241
Version Information: Microsoft .NET Framework Version:4.0.30319;
ASP.NET Version:4.7.2556.0
Here is what I tried:
Followed the fwlink and it actually redirects to github that appears to be some open source version of the compiler that will support my old code. I have no interest in doing that.
Reading the answers to this question: Compilation Error when change .Net framework from 4.5.2 to 4.5 in VS 2015 Community edition
I tried to follow the instructions, but those instructions seem to be for a MVC project and my project is a Web project [Note: I am new to Visual Studio so I probably have that wrong] but what I am sure of is:
a. I don't have a project file.
b. I see a globe icon on my project.
c. When I right click on the project (globe icon thing in solution explorer) I do NOT get a Properties menu item.
So, how do I get past this error where my preference is to update my code to current techniques rather than patch together libraries to get it to run.
[EDIT] This problem just occurred on a different project/solution that actually does have a project file. This was converted from VS2005 to VS2017 a couple of months ago and has been working fine. I suspect some configuration change in VS2017 that is affecting all solutions.
[EDIT] The comment about out of memory seems promising except it fails in exactly same spot every time. A reboot did not help. This is an i7 with 16GB and 500GB SSD with 400GB free. If it is running out of memory it might be some config in VS that artificially limits memory of that particular process. I am going to deeper into this lead.
[EDIT] I have IIS Express 10.0.1740 installed.
[EDIT] I tried installing the Roslyn compiler using nuget. The error message did not change, but it could be I need to do some additional config to get it to be the compiler used for this solution/project. The problem is happening while the application is running so presumably iisexpress is doing the compiling.
[EDIT] This is also happening on a different project that does have a .vbproj file. I suspect some update that is causing the issue.
[EDIT] I am now testing in a project that has a .vbproj file. To change target framework I do Project -> XXX Properties -> Application -> Target Framework 4.6.1. The problem still happens. Note the warning in the message that it may require additional hand edits. I did not know what to edit, so I did not make other changes.
[EDIT] Note that the compiler version is 14.7.2556 And it is complaining about being for VB2012. This seems to conflict with https://en.wikipedia.org/wiki/Visual_Basic_.NET that says that vb compiler 14.0 came out in 2015.
[EDIT] I did not have a section in web.config, so there is nothing to remove.
[EDIT] I do not have a compilerOptions= tag in web.config, so there is nothing to change.
With a an i7 with 16GB and 500GB SSD with 400GB free I doubt this is a memory issue, I'm guessing the ERROR_NOT_ENOUGH_MEMORY is a symptom of the root cause:
This compiler is provided as part of the Microsoft (R) .NET Framework, but only supports language versions up to Visual Basic 2012,
In other words the compiler only works with projects upto 2012, so lets just change what commpiler we use by targeting an up-to-date version of the .Net Framework (right click on Project > Property Pages):
You also can safely remove the CodeDom that's used for Dynamic Compilation in the web.config:
<system.codedom>
<compilers>
<compiler language="c#;cs;csharp" extension=".cs"
type="Microsoft.CodeDom.Providers.DotNetCompilerPlatform.CSharpCodeProvider, Microsoft.CodeDom.Providers.DotNetCompilerPlatform, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"
warningLevel="4" compilerOptions="/langversion:6 /nowarn:1659;1699;1701"/>
<compiler language="vb;vbs;visualbasic;vbscript" extension=".vb"
type="Microsoft.CodeDom.Providers.DotNetCompilerPlatform.VBCodeProvider, Microsoft.CodeDom.Providers.DotNetCompilerPlatform, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"
warningLevel="4" compilerOptions="/langversion:14 /nowarn:41008 /define:_MYTYPE=\"Web\" /optionInfer+"/>
</compilers>
</system.codedom>
Or you could change the compilerOptions="/langversion:6 compiler version.
If this doesn't work, make a cut down https://stackoverflow.com/help/mcve in VS2005 that we can reproduce the problem with and upload the solution somewhere we can download it.
#jmcilhinney you were on the right track. I worked with #Michael Potter and found that, on the local machine, IIS is having trouble doing the just-in-time compile a "Website" requires. I've no deeper knowledge than that (and not sure I want any) but the issue was fixed (in this case) by switching to HTML pages (it is mostly a SPA site).
Had we more code-behind than we do, I would simply switch to a "Web Application".

Trouble getting TeamCity to build F# projects

I'm trying to get our build server (TeamCity 8) to build an F# project (the first any of us have ever created on my team).
When I first ran the build I got the following error:
The value "" of the "Project" attribute in element <Import> is invalid. Parameter "path" cannot have zero length.
I assume that this means that the requisite F# tools are not present on the build server. I tried to rectify this using instructions on this blog post: http://www.heartysoft.com/ashic/blog/2013/3/build-fsharp-3-on-build-server-without-vs (summary: download and install VWD_FSharp.msi) but the problem persisted. I then added Condition="Exists('$(FSharpTargetsPath)')" to the Import tag in the fsproj so that it now reads:
<Import Project="$(FSharpTargetsPath)" Condition="Exists('$(FSharpTargetsPath)')" />
which I saw in another blog post, but all that's done is swapped the earlier error for a new one:
The target "Rebuild" does not exist in the project.
Any help here would be greatly appreciated; I really don't want to install VS on the build server. The only thing about our environment that might be noteworthy is that we're on .NET 4 rather than 4.5.
Thanks
Thanks for your question Ganesh, I have since solved the problem.
So, installing the F# tools using the link in my question did work, but after some digging round in the MSBuild directories it turns out that it only installed F# v3; my projects were targeting v3.1 (the default version in VS2013).
Going into each project's settings file and retargeting for 3.0 solved the problem.

MonoDevelop - Bug with SmartAssembly

I have my dlls (.NET4) build with msbuild and obfuscated with SmartAssembly 5.5.
After that i set them with reference for simple console application in the MonoDevelop (latest) on Mac (10.8).
Built ok, but when i ran that simple app, i have a message:
Unknown heap type: SmartAssembly
I asked SA support but no luck yet (the saproj have item blabla(supports Mono) checked.
I dont see how to attach a screenshot, but, when i run my application i see in the console that message twice. It appears before program stops on the breakpoint on the first line of code.
So maybe someone knows what to change in SmartAssembly or in MonoDevelop to remove this problem ? Thanks
Many .NET obfuscators change the assemblies such that they are not technically correct assemblies (they fall outside the .NET assembly specs) but such that they still run on the Microsoft .NET runtime by exploiting bugs specific to Microsoft's implementation. I suspect they do this to make it harder for assembly reader tools/libraries to load the assemblies. Unfortunately, this also prevents Mono runtime from loading the assemblies. In general Mono has a policy of not "fixing" support for this kind of invalid obfuscated code, so you'll need to ask SmartAssembly support for help.
If you're certain you're compiling with SmartAssembly's "Strictly valid" option and it's not working, perhaps you could perhaps try their "Basic" option.

Building web sites for AnyCpu

I have a .Net 3.5 web site project which I am developing in VS2010 (recently moved form VS2008) and building/deploying with MSBuild and TeamCity. I am using Msbuild tools version 3.5. The web site project communicates with a couple of COM components via Interop-dlls. As I understand, these interops are generated by Visual Studio as a wrapper for the COM component. My problem is that when the application is built and deployed using Microsoft.WebDeployments.targets I get a runtime error message saying:
Could not load file or assembly
'Interop.cvvToolkitLib' or one of its
dependencies. An attempt was made to
load a program with an incorrect
format.
After googling for similar problems I have found alot of posts saying that building for "AnyCpu" should fix this problem, since the tool that is generating the interops defaults to x86.
So I opened my build script and tried to specify the platform as AnyCpu:
<Platform>AnyCPU</Platform>
Still same problem. More googling hinted that it might be "AnyCpu" or "Any CPU" instead, so I tried both. Still no luck. Other forum posts suggested something like this instead:
<ItemGroup>
<ConfigurationToBuild Include="Release|Any CPU">
<FlavorToBuild>Release</FlavorToBuild>
<PlatformToBuild>Any CPU</PlatformToBuild>
</ConfigurationToBuild>
</ItemGroup>
or
<PlatformTarget>AnyCPU</PlatformTarget>
The error remains the same. So my question to you stackoverflowers is: Am I doing something wrong in trying to make the web site build for Any CPU, or is the solution maybe lying somewhere else? Do I have to explicitly pass some arguments in to the <CallTarget Targets="Build"/> ?
I am not very experienced with MSbuild, so I may overlook something important. I have other web applications (not web sites) that are communicating with the same COM components without any issues, so it's only a problem for the web sites. The web applications are build like this:
<MSBuild
Projects="$(ProjectFile)"
StopOnFirstFailure="true"
Targets="ResolveReferences;_CopyWebApplication;_BuiltWebOutputGroupOutput"
Properties="...Platform=AnyCPU..." />
Here I pass the Platform as a property, so I am just guessing I need something similar for the web sites.
The problem was solved by using the 3.5 version of MSbuild. I was using the 4.0 version with 3.5 toolsversion. For some reason that caused the interop dlls to be built on the wrong platform. I have however no idea why it was causing this issue. I have been seeing several strange issues with using MSbuild 4.0 for 3.5-projects. If anyone can enlighten me to why these things happen, I will be happy.