Today I was looking into a .net core app we run on Windows, and wanted to see if I could create some disposable test / review app environments using Docker. In short, it didn’t work great because the .net core app uses Sentry/Raven for c#, and that library is not yet compatible with .net core – so we still have a 4.6 dependency that I had forgotten about. Bummer.

However, I got pretty close to standing it up, and I wanted to drop a few notes here for future me.

App

https://hub.docker.com/r/microsoft/dotnet/

C:\Users\Tim
λ git clone project
λ cd project
# I'm using Docker for Windows, so excuse the funny looking $PWD ahead
#   %CD% in Windows will replace with current directory
λ docker run -it --rm -v %CD%:/app microsoft/dotnet bash
# Now in a linux bash shell with dotnet available
$ cd /app
$ dotnet restore
# Woah it works!
# But then later when I tried building this specific example
#   failed because of the 4.6 dep. But it doesn't have to!

DB

https://hub.docker.com/r/microsoft/mssql-server-linux/

C:\Users\Tim
λ docker run -e ACCEPT_EULA=Y -e SA_PASSWORD=GreatPassword! -p 1600:1433 -v "D:\\SQL DB\\BACKUP\\":/var/opt/mssql/data/bak --rm microsoft/mssql-server-linux
  • I opted to mount my current local directory I use for db backups to see if I could restore a database I had previously backed up on my Windows based SQL Server 2008 and 2012. It worked way better than I expected!!! If you are using Windows, make sure you escape your backslashes (maybe you can get away with forward slashes too?)

A gotcha or two:

  • Make sure if you are using Windows or OSX that Docker is able to access > 3.5 GB of ram. On Docker for Windows in Windows 10, right click the Docker Icon > Settings > Advanced.

docker settings advanced ram

  • SA_PASSWORD is interesting. It’s a disposable container, so I tried setting the password to something dumb like ‘password’. During setup, password policy was upset and complained that I needed to specify a stronger password, which made the container explode. Interesting that the system is telling me, root, what to do!!! sudo make me a sandwich!

  • You’ll notice I forwarded the ports funny. This is because I have normal SQL Server running on my dev machine. I had to change the port it was listening on since it was in use on my host. Which brings me to the most obnoxious part of getting this working…

  • Apparently, unlike the rest of the networking universe, if you want to connect with SSMS on a specific port, the connection is HOSTNAME, PORT not HOSTNAME:PORT. If you use a colon like a normal person, you will never connect to your db. It feels more like a timeout/networking issue than a syntax error, so it was easy to assume something was actually wrong. It’s a comma folks, not a colon.

Conclusion

This worked much better than the last time I tried Dockering around MS technology. Get that .NET 4.6 dependency resolved and toss this stuff in a docker-compose file, and booyah. I love the future.