appsettings.Development.json

[DotNetDublin]

As @harperjohn pointed out it can be a frustration to update the SQL server name within appsettings.json each time you pull a new branch etc.

To avoid this I've removed appsettings.Development.json from the repository and added it to the gitignore file so it won't be tracked going forward.

I've updated the getting started instructions to advise that an appsettings.Development.json should be created and what value needs to be changed.

It should now be the case that once you do this your appsettings.Development.json file will remain constant even if you switch branches etc.

To test this you can fetch the main branch, create the appsettings.Development.json file, update the server name and then switch to the application-branding branch.

All going well your appsettings.Development.json will remain present and unchanged.

Let me know if the above works for you and whether you see any problems with the above approach.

Cheers!

[adamfoneil]

I recommend everyone use (localdb)\mssqllocaldb as the server name, and keep tracking appsettings.json. This server name should be valid in everyone's local environment. This also makes integration testing easier (with one of my libraries for example, but there are others that do this). For example:

https://docs.microsoft.com/en-us/sql/database-engine/configure-windows/sql-server-express-localdb?view=sql-server-ver15#automatic-and-named-instances

The "automatic instance" info is what's helpful here.

[DotNetDublin]

Thanks for this @adamfoneil

Can I just confirm below is the connection string you would suggest using as the default in appsettings.json?

"DefaultConnection": "Server=(localdb)\\mssqllocaldb;Database=TimeKeeper;Integrated Security=true;MultipleActiveResultSets=true"

To clarify we're still tracking appsettings.json, it's appsettings.Development.json we've stopped tracking so if anyone needs to use a different connection then they can set the connection in appsettings.Development.json and won't have to change it each time they fetch a new branch.

Finally for whatever reason (localdb)\mssqllocaldb doesn't work on my own local machine however I'm happy for this to be the default in appsettings.json if it will work for most people.

[adamfoneil]

yes, sorry my screenshot was from another app. The db name should certainly be TimeKeeper. And I overlooked initially that you were talking about appsettings.Development.json. I'm actually not sure of the git tracking implications there, but agree there needs to be some way to override your local connection string without changing every time you get a branch.

If (localdb)\mssqllocaldb doesn't work, I'm not sure about that either. That topic I linked above indicates that LocalDb is installed with the ASP.NET web dev workload in Visual Studio. In my experience, it's always "just worked."

[DotNetDublin]

Okay the problem is not with (localdb)\mssqllocaldb but with me (what a shock!).

As the below shows I have the TimeKeeper database on my SQL Server 2019 instance. I'll go ahead and create a pull request to set the default connection string to the one you suggest and if it becomes a problem later that we're not tracking appsettings.Development.json we can relook at things.

[AnkurSheel]

To clarify we're still tracking appsettings.json, it's appsettings.Development.json we've stopped tracking so if anyone needs to use a different connection then they can set the connection in appsettings.Development.json and won't have to change it each time they fetch a new branch

Can we not add appsettings.Development.json so that anyone new starting with the project does not have to create the file themselves. I think if we add it to .gitignore after it has been committed, it will be in the repo but further changes would not be tracked so that if anyone needs to override it, they can.

Also, @adamfoneil raised a good point of having a consistent connection string so that we can use it for integration tests.

This might be overkill but we could always look at creating a docker container so that the dev setup is consistent for everyone.

[DotNetDublin]

Thanks @AnkurSheel. Good points.

I think if we add it to .gitignore after it has been committed, it will be in the repo but further changes would not be tracked so that if anyone needs to override it, they can.

I have to admit that when it comes to Git I'm more user interface than command line and I notice that in Visual Studio once a file is in the repository you don't have the option to ignore the file which would add it to .gitignore. I haven't tested whether the above could be achieved by manually adding appsettings.Development.json to the .gitignore file or whether it can be achieved by running a git command. I can take another look later.

Also, @adamfoneil raised a good point of having a consistent connection string so that we can use it for integration tests. This might be overkill but we could always look at creating a docker container so that the dev setup is consistent for everyone.

I think 99.99% of people will be using (localdb)\mssqllocaldb and I'll switch over to using this too. That said I don't mind getting exposure to Docker through the project at some point as I don't currently have experience in it.

[harperjohn]

I have used Docker in the past for various things (with great success!)... but not for Visual Studio dev environment/deployment stuff... but this has recently "gotten brighter on my radar" of things to look into. It may not be a high priority for this project/effort at this time... but if others have interest in this, I am also definitely interested! I think that Docker/containers (for development and deployment) is an important (and growing) topic!

[AnkurSheel]

Cool. I will see if I can get a basic docker container going this week.
The client is going to be an interesting one since I think I will have to play around with nginx configs.