I'm updating projects in a .NET Framework solution containing a DLL and an EXE to target .NET 5.0. Every call from the from the EXE which touches the DLL is marked with the warning:
Warning CA1416 'MyDllClass.MyProperty<int>(ref int, int, string)' is supported on 'Windows' 7.0 and later
The suggested actions from Microsoft basically amount to either adding cruft to every call or just giving up and suppressing the warnings. Logically, I expected to be able to mark my EXE to declare that it was targeting Windows 7.0 or higher, so that it would give an exception if anyone tried to run it elsewhere, but the compiler could assume this was the baseline for all API calls. Two things I tried, neither of which helped:
Attempt 1
<SupportedOSPlatformVersion>7.0</SupportedOSPlatformVersion>
Attempt 2
<TargetFramework>net5.0-windows7.0</TargetFramework>
What is the elegant way to address this situation? The fact that I'm in control of both projects seems like the best-case scenario.
From EXE Project:
<OutputType>WinExe</OutputType>
<TargetFramework>net5.0-windows</TargetFramework>
<UseWPF>true</UseWPF>
From DLL Project:
<TargetFramework>net5.0-windows</TargetFramework>
<UseWPF>true</UseWPF>
Thanks to a comment by Hans Passant, I tried removing this from my EXE project:
<GenerateAssemblyInfo>false</GenerateAssemblyInfo>
I also had to remove the AssemblyInfo.cs due to auto-generated fields conflicting with fields defined in there. After that, all good, no warnings. I presume the compiler is generating whatever fields it needs to keep itself happy.
I also guess that this would not be an issue on a green-field project and that I only ended up with that element somewhere in the process of migrating the application.
I have been trying to resolve .dll dependencies for the executable file with Dependency Walker. Currently, I am getting missing .dlls in the following form:
API-MS-WIN-XXX
EXT-MS-WIN-XXX
For example:
API-MS-WIN-APPMODEL-IDENTITY-L1-2-0.DLL
API-MS-WIN-APPMODEL-RUNTIME-INTERNAL-L1-1-0.DLL
API-MS-WIN-BASE-UTIL-L1-1-0.DLL
API-MS-WIN-CORE-APIQUERY-L1-1-0.DLL
EXT-MS-WIN-RTCORE-NTUSER-SYSCOLORS-L1-1-0.DLL
Does anybody have any ideas on how to resolve these?
Any help will be greatly appreciated!
Additional info: I compiled the executable using Visual Studio 2013. The most interesting thing is that I did not receive any errors during compilation. However, I cannot run it due to missing dependencies. I also attached a screenshot of dependency walker:
Update 1: As an attempt to solve the problem I tried to add the path for the libraries that VS used during compilation to the $PATH environment variable without any luck (Dependency Walker still shows unresolved dependencies).
These are API-sets - essentially, an extra level of call indirection introduced gradually since windows 7. Dependency walker development seemingly halted long before that, and it can't handle API sets properly.
So these are all false alarms and nothing to worry about. You're not missing anything.
Also see On API-MS-WIN-XXXXX.DLL, and Other Dependency Walker Glitches.
Edit: Only in Oct 2017 did someone finally try to fill this gap. Meet Dependencies by lucasg. I've only briefly fiddled with it until now, but it handles API sets well and is at least very worthy of attention.
In addition to what #Ofek Shilon said, I usually ignore following dlls that dependency_walker identified as missing when I try to find missing dlls for my program. You will see that your program runs fine when dependency_walker says these dlls are missing.
API-MS-WIN-*.dll
EXT-MS-WIN-*.dll
IESHIMS.dll
EMCLIENT.dll
DEVICELOCKHELPERS.dll
You can search for dlls other than the ones above to resolve your problem.
Dependencies program helped me find a missing DLL in no time. It is open source and available here: https://github.com/lucasg/Dependencies
I also ignore:
EFSCORE.DLL
WPAXHOLDER.DLL
I created a multi-module project with a single sonar-project.properties. Most of the project is in c but one module is c++. I left the sonar.language property blank and ran sonar-runner with analysis.
The project and modules were created in the database and everything looked OK but when I did a preview on the same code I had a large number of new issues on the c++ project.
On closer inspection I found that the module in sonarqube was all wrong - it consisted of only the header files (.h) and most of the issues were the use of C style comments. It seems that the module was identified as a C module so all the .cpp files were ignored. However, in the preview the language was identified correctly and issues were found in the .cpp files that were clearly not know to sonarqube.
I cannot find any place in the UI to change the language of a module nor can I figure out a way to force it after the fact in my sonar-project.profiles.
First, sonar.language is apparently deprecated, and second, using module.sonar.language=cpp caused an error:
Caused by: sonar.profile was set to 'DEFAULT_C' but didn't match any profile for any language. Please check your configuration.
DEFAULT_C is something that we use for projects generally but not the one I'm working on. I have different profiles set up for different languages via the UI, but if I cannot get the analysis to see the correct language it doesn't help me much.
Any one have any idea how I can force the language of a module after the fact?
Hmm. I considered just deleting this but if I had found an answer on stackoverflow it would have eased my pain a little.
Brute force works.
Just set the language and the profile you want for the moudle and ignore complaints about such things being deprecated. Chosing a language won't force the right profile even if you have set up an explicit profile for the language in the UI - so just state it in the sonar-project.properties file.
In my case:
module.sonar.language=cpp
module.sonar.profile=MY_CPP_PROFILE
Throw sonar-runner at that and it will beat the backend into shape.
Since I upgraded to VS2012 and Resharper 7, my previously working MS Tests are not running anymore.
The tests are run in an ASP.NET environment. I use the following Attributes:
[TestMethod]
[HostType("ASP.NET")]
[AspNetDevelopmentServerHost("C:\\Projekte\\****\\Website", "/")]
[UrlToTest("http://localhost:7924/")]
Any idea how to fix this?
As odd as it is, using VS2012, using Resharper 8.0, using NUnit, I was receiving this error because of an entry in my app.config file. I added an EntityFramework connection string and this behavior started. Removing the entire connection strings section shows the test runner starts/works again. Viewing output shows the app.config is not valid - this was causing this specific behavior in the test runner - "Test wasn't run".
I had the testproject set to AnyCPU and the project set explicitly to x86 when this happened. Setting the testproject to x86 solved it for me.
I'm using VS2012 R#8 and nUnit
Try running the Unit Tests using the MSTest Test Explorer. You might find more details in the output window of the root cause.
For me, it was a referenced assembly that was using a more recent version of NUnit than the one that was referenced in the test project. Using the same up-to-date version fixed the problem.
System.IO.FileLoadException: Could not load file or assembly 'nunit.framework, Version=2.6.3.13283, Culture=neutral, PublicKeyToken=96d09a1eb7f44a77' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference.
I'd same problem I just..
Changed methods access modifier from private to public.
Removed static keyword from methods.
That's it. It worked for me. But that is for C#.
In my case it was the NUnitTestAdapter nuget that needed to be removed.
Check that any references that you have in the test project are set to Copy Local True.
I had the same problem. Couldn't get the Visual Studio test runner to work, so I tried debugging a test instead. This threw a ConfigurationErrorsException, which didn't have much of a stack trace but contained the phrase "ClientSettingProvider". I searched my solution and found that something had added a appSetting key for "ClientSettingProvider.ServiceUri" to my app.config. I deleted this (along with an empty connectionStrings element) and rebuild everything - fixed the problem!
Double check your app.config and try deleting any empty elements or anything that looks fishy.
Another (silly) problem it might be; I accidentally had the project set to not build. Go to Build/"Configuration Manager", and ensure the project is set to build.
Using VS2010 and ReSharper 9.1 the issue was that the file LocalTestRun.testrunconfig was missing but was referenced in my .vsmdi file.
The test without VS were running properly but I always had the "Test wasn't run" error in ReSharper test UI.
So I simply restored my old LocalTestRun.testrunconfig file and everything run perfectly.
I probably could have updated my .vsmdi file to not reference the missing file... I did not test that.
On VS2012, Test Project don't work on Shared Folders like \XXXXXX\XXX
I solved it copied the Test Project on local devices.
Good Luck
I found that the settings file for the unit test may need checking as to which one is being pointed to by ReSharper. I had the same thing happening and it was down to my unit tests for the RS Harness pointing to the wrong file.
I had the same issue because the test class name had the characters '<' and '>' in it (also '(' and ')' caused this issue).
Removing those symbols fixed the problem.
I could use symbols in identifiers thanks to F#'s Unicode support.
I had the exact same issue and nothing helped.
eventually I saw that I had a mismatch in my namespaces of the unit project and the unit test project.
The namespace of my unit project is unit.project and the test project was named unit.project.tests but the default namespace of the test was the same as the unit, both was unit.project.
Once I've updated the namespaces to be different (one namespace for each project) everything worked!
I had a similar problem with NUnit test, which would not be executed, but R# would only mark them as "Test wasn't run".
Executing them with the native NUnit runner revealed, that the app.config file had an error (actually, 2 ConnectionString sections). Fixing this also made the tests running in R# test runner.
I kept getting "Test wasn't run" in Resharper.. I tried all the recommendations but nothing worked. What solved it for me was running Visual Studio as Administrator. (VS2013 w/ Resharper 8.1)
Just an excerpt from MSDN regarding
Assert.Inconclusive:
The code generated by Visual Studio when creating unit tests includes
an Inconclusive statement as a placeholder.
It happens if something is wrong with the solution, the most often a misconfiguration, like wrong or mismatched namespaces, inconsistent build targets etc, what leads to the fact that UnitTestExplorer is unable to use provided unit tests properly. So the general solution is to check latest changes and fix errors.
I had the same problem in C#: Unit tests run by ReSharper all just stopped with "Test wasn't run". No other information.
It turned out to be due to my custom section in App.Config. Removing that and it worked.
Configuration: Visual Studio C# 12, ReSharper 8.2.3
It could be also that Your solution contains multiple versions of i.e. nUnit installed in different projects. In my case this was the reason of the problems. After unifying the nUnit version in the solution, the problem was gone.
Just to add to this, I had written over my app.config file with a new one that was missing some sections I needed. I added the sections back in, at which point I got this same error in resharper. Thanks to the comments above I compared it to an older version and found that I was missing the section names in the configSections.
I'm running VS2010 Version 10.0.30319.1 RMTRel
I've noticed problems compiling VB.NET application. When I "rebuild" the solution it reports the build was successful. When I then click the run icon to begin debugging, then the compiler will report build errors(often related to referenced projects). I've confirmed all the projects are targeting the same framework and after an undeterministic number of times repeating the same steps, it will eventually compile. This seems consistent enough to me with other code bases to believe that it's a problem with VS. Anyone have any thoughts that might help improve my experience?
You should also check your configuration manager - probably some of projects are disabled for building in current build plan.
is this a rather large solution? If so, the order of build may be out of whack and the way to solve that is to set the build order of the projects to make sure all of the dependent projects are built first.
One common reason is circular references. You cannot do this in a pair of projects, but it can be done if you cobble together a long string of projects. The way to catch this is a dependency mapping tool with a visual representation of dependencies. You will see the items that refer back up to the top.