Asp.net

If you’re new to Docker, it’s hard figuring out even what to search for, and how the concepts tie together, let alone what to pay attention to for your use case.

To make things more difficult, there has been a lot of change over time, and stuff that was once recommended is now not recommended. For example, a lot of older video tutorials recommend using container links which have since been deprecated in favor of user-defined bridge networks .. in case you’re unfamiliar with this, I’ll cover what this means, and why you’d use it later in the blog post.

Once you learn the basics, using Docker in practice is fairly straightforward, and if you’re using Docker at home or at work, the time you spend learning now will save you a massive amount of time and effort in the future.

If you’ve used Docker a bit, are familiar with some of the concepts, how dabbled here and there, but sometimes struggle with connecting some of the concepts, or how to get things set up end-to-end, then this blog post is for you.

In this blog post, I’ll guide you through step by step on:

• The distinction between docker image and containers
• Best practices on how to persist data within containers, and how to control where data is persisted
• How to continue developing on your local machine as usual, while your app is running within a docker container on your local machine
• How to connect your containerised web app to a containerised Microsoft SQL Server

Fiddler is an awesome tool for debugging web services. For the last 10 years, I’ve been using it virtually every working day for web service debugging in scenarios such as:

• Capturing HTTP requests as they travel through a distributed system, which you have set up on your local development machine.
• Intercepting and modifying HTTP requests, essentially performing a local man-in-the-middle interception. This is particularly useful if want to modify HTTP requests to simulate functionality which isn’t currently present, modify HTTP headers, etc.
• Replaying captured requests - useful if you are debugging the way a web service behaves, given a specific request; capture the request, and replay it as many times as you need in order to debug the error.

If you’re doing any work with web services, Fiddler is definitly worth considering. Setting it up is fairly straightfoward

By default, Fiddler can update your browser proxy to route through the Fiddler proxy, which is, by default on port 8888, and will capture requests between Chrome/Firefox/Safari/etc, and your web app.

What if you’re debugging locally, and want to intercept .NET services which call other web services? i.e. Web Browser -> Web App -> Service1 -> Service2 (the one you want to debug)? This can be done by setting defaultProxy in web.config. In this case, since we want to debug Service2, we’d set defaultProxy in Service2’s web.config file.

i.e.

<configuration>
 <system.net>
  <defaultProxy>
   <proxy bypassonlocal="false" usesystemdefault="true" />
  </defaultProxy>
 </system.net>
</configuration>

With one of the distributed apps I frequently work with, I was setting, and resetting the web.config defaultProxy fairly frequently. To save some effort, I wrote a script to automate the change.