Paths /ASP.NET/Https and /Microsoft/UserSecrets) not shared on mac

This issue happens when you open, in Visual Studio for Mac, a project that was created using Visual Studio for Windows. Since most developers on my team are using Windows computers, I wanted to find a solution that would allow me to run the project without modifying its configuration. It required a lot of time and research, but I finally made it work:

1. Check if the folder ~/.aspnet/https exists. If it does, skip to step 5.

2. Create the folder structure ~./asp.net/https.

3. Run the command below to install the development certificates that allow you to access localhost through HTTPS. More details here.

   dotnet dev-certs https --trust

4. Run the command below to export the development certificate. Take note of the password as you will need it later:

   dotnet dev-certs https -ep ${HOME}/.aspnet/https/FILE_NAME.pfx -p PASSWORD

5. Check if the folder ~/.microsoft/usersecrets exists. If it does, it means you already have some User Secrets defined, so you can probably skip to step 7, otherwise, continue below.

6. Get the User Secrets ID for the Assembly of the Web Application you're building. It is usually located in a file named like Your.Project.Package.Name.Assembly.cs. You can also search for UserSecrets.UserSecretsIdAttribute(" in your project folder and take the GUID.

   You might need to repeat this step for multiple assemblies in your solution if you're using Docker Compose to deploy more than one Web application at the same time.

7. Inside ~./microsoft/usersecrets, create a folder with the GUID you got on step 6, assuming one does not exist already. If it does, you can simply update the file secrets.json inside it with the contents of the next step.

8. Create the file secrets.json and insert the following:

   {  "Kestrel": {    "Certificates": {      "Default": {        "Path": "/root/.aspnet/https/<FILE_NAME from Step 4>.pfx",        "Password": "<PASSWORD from Step 4>"      }    }  }}

9. Create a file named .env in the same folder where your Docker Compose configuration files are located inside the solution with the following content:

   APPDATA=/Users/YOUR_USER_NAME

   This file will be picked up by Docker Compose automatically when Visual Studio runs the tool.

10. Add the file .env you just created to .gitignore, so it doesn't get committed with your changes by mistake. This will ensure other developers with different environments can use this approach as well.

11. Create a symbolic link to point ~/ASP.NET to .aspnet as follows:

    ln -s ~/.aspnet ~/ASP.NET

12. Create a symbolic link to point ~/ASP.NET/Https to ~/.aspnet/https as follows:

    ln -s ~/.aspnet/https ~/ASP.NET/Https

13. Create a symbolic link to point ~/Microsoft to ~/.microsoft as follows:

    ln -s ~/.microsoft ~/Microsoft

14. Create a symbolic link to point ~/Microsoft/UserSecretsto~/.microsoft/usersecrets` as follows:

    ln -s ~/.microsoft/usersecrets ~/Microsoft/UserSecrets

If you follow all steps correctly, Docker Compose will be able to resolve the Windows path in your Mac environment, find the required certificate password and run the solution correctly.

The outcome is that you only need to commit your .gitignore changes to make sure your .env file doesn't get included in the repo by mistake affecting others unintentionally - no further changes are required to the project.

Edit on August 4th, 2019: Some symlink creation parameters were in reverse order. Huge thanks to @BRBdot for pointing it out.

References:

1. Hosting ASP.NET Core Images with Docker over HTTPS
2. Developing locally with ASP.NET Core under HTTPS, SSL, and Self-Signed Certs
3. How to setup the dev certificate when using Docker in development

As mentioned by @Leonardo Braga, this issue happens when you open, in Visual Studio for Mac, a project that was created using Visual Studio for Windows

I have used the following steps to solve this problem on Visual Studio Mac:

1. Take the backup of the docker files and docker compose project, so to be in the safe side.
2. Delete the docker files and the docker compose project from the solution and respective projects.
3. Re-generate the docker files and docker compose by right click on the project and Add -> Add Docker Support

This is to me the easiest way to resolve the above issue.