In .NET Core 2.1/2.2, the default config behavior was not to copy to the output directory and copy to the publish directory by default. In .NET Core 3.0, this behavior was changed to copy to output & publish directory by default. This is a breaking change for many customers.
Run a sample .NET Core app in VS 2017 & 2019 and config files copied to output & publish directory is different.
Have an msbuild property to switch back to the old behavior
This is the PR that introduced this change - https://github.com/aspnet/websdk/pull/593
Can we get this also for the new worker templates? We have integration tests that references frontend projects and copying the appsettings.json to bin folder, does so that it is also be copied over to the integration test and interfering with the appsettings.json from the integrationtest project. I am struggeling with this already with general console apps, and was hoping that the workertemplate would behave like the webtemplate.
appsettings.json and properties\launchsettings.json is copied to bin folder in 3.0.100-preview9-014004 and not in 2.2.401
/cc @davidfowl
We should have an msbuild property to opt into the old behavior.
In the meanwhile, you should be able to avoid this by adding this to your project file:
<ItemGroup>
<Content Update="**\*.json" CopyToOutputDirectory="Never" />
<Content Update="**\*.config" CopyToOutputDirectory="Never" />
</ItemGroup>
Interesting. Maybe we should just copy appsettings.json
In our case. Appsettings.json has our sql connection string in there, we deployed to staging (and have our staging SQL string in git). Then we deployed to master with VS2019, it overwrote our SQL string and took our website down.
VS2017 on the other hand, did not copy it. So to make matters worse, reverting to VS2017 didn't even fix the problem.
So I would request that you have an option to completely revert to VS2017 behaviour, or you some how tell every nopcommerce user that VS2019 will brick their production websites when they upgrade to VS2019 and the copy behaviour changes.
Sure it is easy enough to change and work around, but this change was completely unknown and in my opinion a breaking change as it took down our production website and left us with no idea why.
In our case. Appsettings.json has our sql connection string in there, we deployed to staging (and have our staging SQL string in git). Then we deployed to master with VS2019, it overwrote our SQL string and took our website down.
Can you walk me through this? The change was to copy to the output folder on build. How did this change break your deployment flow?
@rolandh I sympathize but 3.0 is a major version and there are lots of breaking changes. Unfortunately, this one isn't documented as we didn't think it would be considered a breaking change.
This should be documented. In our case it does not break anything for publishing/building but our integration tests started to fail. The reason being that we use UseSetting() in the setup of the testclient. This setting is then overridden by the value in the appsettings.json file. If UseSetting() would have overridden the appsetting.json value we would have been fine.
In 3.1, we've added an additional flag to the SDK - ExcludeConfigFilesFromBuildOutput that should prevent *.config and *.json files from being copied to the build output directory. They would continue to be published similar to 2.x. We have a follow up issue to document this as part of the 3.1 release: https://github.com/aspnet/AspNetCore/issues/15088. Lastly, for users on 3.0, the workaround listed here: https://github.com/aspnet/AspNetCore/issues/14017#issuecomment-531882022 would be the way to go.
Great result.
Most helpful comment
In 3.1, we've added an additional flag to the SDK -
ExcludeConfigFilesFromBuildOutputthat should prevent*.configand*.jsonfiles from being copied to the build output directory. They would continue to be published similar to 2.x. We have a follow up issue to document this as part of the 3.1 release: https://github.com/aspnet/AspNetCore/issues/15088. Lastly, for users on 3.0, the workaround listed here: https://github.com/aspnet/AspNetCore/issues/14017#issuecomment-531882022 would be the way to go.