When attempting to Dockerize my ASP.NET Core micro-service, I ran into an interesting issue. We use Docker’s Network feature to create a virtual network for our docker containers; but for some reason I wasn’t able to issue a curl request against the ASP.NET Docker container, it simply returned:
curl: (52) Empty reply from server
Well crap. Docker was set up correctly; and ASP.NET Core applications listen on port 5000 typically:
COPY $source .
ENTRYPOINT ["dotnet", "MyProject.dll"]
dotnet run output:
Hosting environment: Production
Content root path: /app
Now listening on: http://localhost:5000
Application started. Press Ctrl+C to shut down.
Hm. It’s listening on localhost (the docker container), and I’ve exposed port 5000, right? Maybe my port settings are wrong when I spin up the container? Let’s check:
docker run -i -p 5000:5000 --name my-project -t my-project:latest
That checks out. The syntax for docker
HOST:CONTAINER, and I’ve made them 5000 on both sides just for testing, but I’m still not getting a response.
I found out that by default, ASP.NET Core applications only listen on the loopback interface — that’s why it showed me
localhost:5000. That doesn’t allow it to be viewed externally from the host. Sort of a bonehead moment on my part; but there you are. So to fix it, I can tell Kestrel to listen using the
UseUrls() method and specify interfaces to listen on:
public static void Main(string args)
var host = new WebHostBuilder()
.UseUrls("http://*:5000") //Add this line
Now, it will listen to all network interfaces on the local machine at port
5000, which is exactly what I want.
I updated .NET Core 1.0.1 to .NET Core 1.1.0, and am no longer able to ‘Start Debugging’ (F5) from Visual Studio 2015.
When I tried to debug, I’d get the following error in the output console in Visual Studio:
The program ' dotnet.exe' has exited with code -2147450751 (0x80008081).
The program ' iisexpress.exe' has exited with code 0 (0x0).
The latest version of .NET Core is 1.1 (1.1.0 if you’re a package manager type), but Visual Studio 2015 only supports F5 Debugging with .NET Core 1.0.1.
You can still debug .NET Core 1.1.0 Applications in Visual Studio 2015, however. Here’s how:
Open the Package Manager Console (or use cmd.exe).
dotnet run from either console.
You should see the following prompt:
Go to the debug menu in Visual Studio and click “Attach to Process” (or use the Ctrl+Alt+P shortcut).
Look for dotnet.exe, and hold down shift while selecting all the dotnet.exe processes (it’s one of those three; and you can actually select all at the same time).
Click the “Attach” button.
You’ll know you’re debugging because set breakpoints will change from clear interiors to a red interior (indicating the breakpoints have been loaded).
I’ve been working on an ASP.NET Core application; and even though I constantly say I’ll never upgrade in a Dev Cycle, I did.
I updated from .NET Core 1.0.1 to .NET Core 1.1.0, and during the upgrade path, I updated the packages in Nuget using Visual Studio, and suddenly, everything stopped working, specifically I’d get the following error when trying to build:
Can not find runtime target for framework '.NETCoreAPP, Version=v1.0' compatible with one of the target runtimes:
It turns out, Nuget modifies the project.json file in Visual Studio in one specific crucial way: It changes what was previously:
"type" : "platform"
Notice the difference? the former JSON is an object, and Nuget replaces it with a string. To fix the error, simply make that line look like the object it was previously:
"type" : "platform"
This error should only happen if you try to upgrade in Visual Studio.
By default, the project output name when building your .NET Core project is the same name as the directory/folder that contains the
project.json (which will be back to *.csproj) as of Visual Studio 2017. So if you’re like me, and you keep your projects like so:
- <snip>Lots of *.cs files and folders</snip>
Then you’re going to run into a problem because the name of your output file will be
src.dll, since the containing directory is
src. Not what you want.
To fix this, you can change a setting in the project.json (or the ProjectName.csproj file):
For project.json, under the
"outputName": "MyProjectName" //add this
outputName property, and your string value will be the name you want to be emitted for your DLLs and settings.
For ProjectName.csproj in Visual Studio 2017, it’s the same property:
This will allow you to name the project whatever you want, and not be dependent upon the convention of the folder name as project name.
Last week I went through Five Reasons Why I left the Startup Life; and I received a lot of good feedback on the post. Some of the feedback I received was that that post seemed negative, and looking back, of course it does (after all, it’s about why I left the startup life). But it doesn’t tell the whole story. While there are reasons why startups have more difficulties than other more established businesses, that isn’t to say you shouldn’t join a startup. In fact, I think if you have the risk tolerance, you should join a startup at least once. Here’s why:
You will learn far more in a startup than a corporate job. Since there is generally no support structure in a startup, you learn a lot very quickly. I had never programmed firmware before joining a startup, and my C would be best described as “non-existent” (I don’t consider a college course more than 14 years prior to be useful). Not only did I have to learn C, but I also had to learn how to ship firmware for a hardware product. That would never have happened in a corporate job. No one would have said, “Sure, let’s have this person who’s never shipped firmware before write our firmware.” In a startup, you often don’t have any other choice than to just do it.
You will shake your fear of shipping. There is a vast gulf between developers who can ship software and developers who can not. In a corporate job, it’s really easy to make changes to the software without moving the shipping needle at all. In a startup, if you don’t write software that directly contributes to shipping that software, it just won’t ship. It’s scary at first, but once you start shipping, you’ll be addicted to it and wonder how any software team can ever work any other way.
You will have no process to get in your way of shipping. Once businesses have shipped software, they assume risk for shipping software. If you don’t have any software, you don’t have any risk to shipping software. Your risk is purely the act of shipping. That’s part of the reason why startups don’t have any process around shipping. There’s no risk, because nothing is already shipped! In your corporate job, you know the word “change management”, and it probably makes you shudder. You have meetings upon meetings about change management, and you wish you could just ship software. In a startup, you will.
You control the culture of software and its architecture. While there are other parts of startup culture you can’t control, you will at least have control over the software aspects. Do you want to use AWS? Great. Want to use React? Sure. Want to make sure your software is open source? You can do that.
You will leave work fulfilled, and if you don’t, you only have yourself to blame. In a lot of businesses, there are multiple factors that affect happiness that you don’t control. Too much risk around using your favorite language, too much risk around shipping that neat feature. Every change takes the sign-off of three different people, two of which you don’t interact with when making that change. In a startup, it’s just you. No one can keep you from shipping software that solves your business problem. There’s a study that says people are happier when they exhibit control over their environment. Startups are as close as you’ll get to being in control of your environment (short of owning your own company).
There are lots of reasons to join a startup that I do justice to here, but I really think you should consider it at least once, and when you do, consider it with eyes wide open.