New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ConfigurationManager doesn't find config file with "dotnet test" #22720
Comments
Should we override the entry assembly in NUnit Test Adapter? |
The app.config in effect is testhost.dll.config, not MyTests.dll.config which @gboucher90 needs. |
I still don't understand the problem / ask here: Is there need to share the app.config between normal execution and NUnit execution? Is that the underlying problem? |
@karelz The author wants to load his app.config while testing, for any of a number of possible reasons. Maybe that's the only way to initialize a component needed for the test, or maybe there are settings that need to be validated. In any case, consider a test project named MyTests. When you build, When you run VSTest, the entry assembly is That means the test will fail because the configuration it directly or indirectly relies on is unavailable. |
Yes it is exactly what @jnm2 explained. I have many tests (mainly integration ones) which relies on App.config data. Using .Net Framework NUnit is able to create a new app domain and specify the entry point. The later is used by System.Configuration.ConfigurationManager to find the correct App.config file. This is not possible anymore and the code under test fails to find the configuration. |
Can your test projects copy the app.config into the "correct one"? |
I don't think so. This would mean overwriting the testhost.exe.config that ships with VSTest in the dotnet sdk path. |
I would expect the entry assembly to be in the output directory (maybe copied from somewhere). Is that not the case? |
@karelz I haven't observed the copying of a test host. This project does not copy a test host to the output directory: <Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFramework>netcoreapp2.0</TargetFramework>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="Microsoft.NET.Test.Sdk" Version="15.5.0" />
<PackageReference Include="NUnit" Version="3.9.0" />
<PackageReference Include="NUnit3TestAdapter" Version="3.9.0" />
</ItemGroup>
</Project> It copies Running from Test ExplorerEnvironment.CommandLine: Assembly.GetEntryAssembly().Location: Running via
|
@JeremyKuhne thoughts on this? |
We're facing this issue too and it's a blocker for our .net core migration. The easiest way to check is to have this inside your test code
And you'll see that instead of referencing What is the intended workaround? What about a patched release? |
+1 ... also seeing this, following for a fix date. EDIT: Our temporary workaround involved adding this to the test project's
|
The intended workaround for this sort of scenario is that you load data from a specific path. ConfigurationManager.OpenMappedExeConfiguration() will let you open any configuration file you want. Is there a reason that won't work for you? |
@JeremyKuhne User level code changes to address behavioral differences between .NET framework + nunit vs .NET core + nunit smells like a kludge. Same concern but to a lesser extent on changes to the build system to account for those differences .NET F/W vs .NET Core differences. I'm new to how vstest and testhost interplay but if they are inserting themselves in the middle, shouldn't they be responsible for maintaining transparency about this abstraction from a user code perspective? Perhaps |
Fundamentally you're kind of stuck with kludges in this case. Configuration files were tied with the The only way you can get consistent behavior without kludges across the platforms if you depend on custom config file locations is to explicitly open your |
Using "OpenMappedExeConfiguration()" is not really an acceptable solution for us. We have many utility libraires referenced by applications and using directly the ConfigurationManager. Thus we cannot hardcode a specific file easily. We would need to inject everywhere the application config file name or the configuration object directly (granted that should have been done in the first place). Anyway we are working on refactoring the code but it is quite costly and it delays the migration to .net core since we cannot run a lot of the test projects (mostly integration ones). We may end up copying the app config file under "testhost.dll.config" but that's something I would really prefer to avoid. |
Especially because that file location is user-account-global state. |
Sorry there isn't an easy answer. :/ Since there is only effectively one AppDomain (one set of statics) one potential way to address this would be for the test infrastructure to copy (or hardlink) the testhost.dll local to the tests to pick up specified configs (by renaming them). |
@JeremyKuhne is there a new recommended approach for application settings and custom configuration for .net core apps? We’re simply going with app.config/*.config just because of existing code but open to recommendations since my team is already porting ... |
You can use ConfigurationManager, of course, but it is a bit heavy. If you do use the config system, using a Configuration instance is, for obvious reasons, recommended. Outside of that, using Json seems to be the prevailing trend. It is easier to comprehend and much lighter weight than System.Configuration. |
Just for the record, I'm using XUnit and having the same problems. The workaround with copy into |
Closing. As stated, the recommendation here is to explicitly construct a |
I would like to see this issue solved in a batter way. One of the main goals of integration testing is to insure that the Data Access Layer is working properly. And we all use the appsettings.json to store the connection string. |
Just noting that this is a significant block to our .NET Core migration too - yes, we can rewrite and refactor, but it's essentially another breaking change to deal with. I've tried the testhost.dll.config hack but as far as I can see that has to go to a path outside the whole project directory (C:\Users\XXX.nuget\packages\microsoft.testplatform.testhost\15.3.0\lib\netstandard1.5\testhost.dll) in my case, rather than the OutDir as suggested by @SidShetye (unless I'm missing something?) - which turns a cludge into something I wouldn't want to rely on at all? |
Just give this one a try, it worked for me: |
https://github.com/dotnet/corefx/issues/32095 created to find another solution. |
With dotnet 3.1 I'm having to reference
The statement below was very helpful for verifying the config path used
|
I was noticing that there were some issues with the .NET Core 3.1 SDK not being found after the VS Preview install, and I had to install the x86 SDK manually. I'm not sure how all that got changed, but it would be nice if the runtime was using the 64-bit SDK again the way it's supposed to be. |
Here's a snippet that should work for both x86 and x64 cases. #if NETCOREAPP
using System.Configuration;
using System.IO;
using System.Reflection;
#endif
...
// In your global setup:
#if NETCOREAPP
string configFile = $"{Assembly.GetExecutingAssembly().Location}.config";
string outputConfigFile = ConfigurationManager.OpenExeConfiguration(ConfigurationUserLevel.None).FilePath;
File.Copy(configFile, outputConfigFile, true);
#endif |
Hello,
When run with "dotnet test" and NUnit, the actual entry point is the "testhost":
.nuget/packages/microsoft.testplatform.testhost/15.0.0/lib/netstandard1.5/testhost.dll
Then it is looking at the wrong place and with wrong name.
Program.cs
App.config
csproj
EDIT: @karelz fixed code formatting
The text was updated successfully, but these errors were encountered: