@richlander Can this get merged? Is there someone else who should review?

Is everyone satisfied with the guidance in the readmes (https://github.com/dotnet/dotnet-docker/blob/master/samples/dotnetapp/dotnet-docker-dev-in-container.md#requirements & https://github.com/dotnet/dotnet-docker/blob/master/samples/aspnetapp/aspnet-docker-dev-in-container.md#requirements)? The guidance is rather open-ended. If there are problems/drawbacks with changing the local bin/obj, perhaps the wording should be adjusted to specifically call out you should only change the container bin/obj path.

To avoid conflicts between container usage and your local environment, you need to use a different set of obj and bin folders for each environment.

Make this change with the following steps:

Delete your existing obj and bin folders manually or use dotnet clean.
Add a Directory.Build.props file to your project to use a different set of obj and bin folders for your local and container environments.

@richlander @MichaelSimons Any update? Can this get merged?

@ajcvickers - Do you have thoughts on the question I posed (#1033 (comment))? I am of the opinion the readme should be updated as well per this change.

@MichaelSimons I have no opinion on that; who would be able to make a call as to whether this is needed or not?

@ajcvickers has anyone tested if a "local" build will overwrite the "container" folder? - the two builds need to coexist without interfering...

If there are problems/drawbacks with changing the local bin/obj, perhaps the wording should be adjusted to specifically call out you should only change the container bin/obj path.

@MichaelSimons yes, I think it is a good idea to reflect this change in the guidance as well. Are you asking that @bricelam makes this changes also in the PR or can you do it after this after it is merged?

@bricelam Can you answer the question from @raix

The guidance and code should be in sync otherwise the samples are not coherant. I think it could be as simple as making the following tweak to the two readmes ((https://github.com/dotnet/dotnet-docker/blob/master/samples/dotnetapp/dotnet-docker-dev-in-container.md#requirements & https://github.com/dotnet/dotnet-docker/blob/master/samples/aspnetapp/aspnet-docker-dev-in-container.md#requirements)).

To avoid conflicts between container usage and your local environment, you need to use a different set of `obj` and `bin` folders for your container environment.

 Make this change with the following steps:

 1. Delete your existing obj and bin folders manually or use `dotnet clean`.
 2. Add a [Directory.Build.props](Directory.Build.props) file to your project to use a different set of `obj` and `bin` folders for your container environments.

Will a "local" build overwrite the "container" folder?

It won't. The output assemblies will be like this. There won't be any overlap.

• bin/Debug/netcoreapp2.2/Sample.dll
• bin/container/Debug/netcoreapp2.2/Sample.dll
• obj/Debug/netcoreapp2.2/Sample.dll
• obj/container/Debug/netcoreapp2.2/Sample.dll