I’ve been working with .NET core recently and I’d like to post some random observations on this subject for the future reference.
It is possible to create Nuget package upon build. This option is actually available also from the VS2017 Project properties GUI. Add this code to
It is possible to add local folder as Nuget feed. The folder can also be current user’s profile. This one is actually not Core specific.
Nuget.config should look like this:
< ?xml version="1.0" encoding="utf-8"?>
You can compile for multiple targets in
.NET Core compatible
csproj. Please note the trailing s in the tag name. You can also conditionally include items in
csproj. Use the following snippets:
There is a reference documentation for the available targets: here.
The listening port in Kestrel can be configured in multiple ways. It can be read from environment variable or can be passed as command line argument. An asterisk is required to bind to physical interfaces. It is needed e.g. when trying to display the application from mobile phone when being served from development machine. The following are equivalent:
The preferred way to pass hosting parameters to Kestrel is
launchSettings.json file located in
Properties of the solution root. You can select a profile defined there when running:
dotnet run --launch-profile "Dev"
dotnet run is used to build and run from the directory where
csproj resides. It is not a good idea to run the app’s dll directly. Settings file can be missing from
bin folder and/or launch profile may not be present there.
Windows Communication Foundation is becoming sort of obsolete in favor of ASP.NET Web API, which has been advertised as primary technology for building web services. However, the latter obviously cannot serve as a full equivalent of the former. WCF still is a powerful technology for enterprise class service oriented architecture. For that purposes, the decision of switching the transport protocol from http to net.tcp sooner or later must be made clearly for performance reasons. From my experience I can tell having 100% working configuration of a service hosted inside the IIS is surprisingly hard and a developer has to face a series of quirks to bring the services back to life. Let’s sum up all the activities that can help make a service working with the net.tcp.
- WCF Non-HTTP Activation service must be installed in Add/Remove programs applet of the Control Panel. It is not obvious, that it is a component of the operating system itself, not of the IIS.
- The TCP listener processes must be running. Check
netstat -a to see if there is a process listening on the port of your choice (the default is 808), check the following system services and start them if need be:
Net.Tcp Listener Service and
Net.Tcp Port Sharing. I have observed cases, where those services were unexpectedly shut down, e.g. after restart of the operating system.
- IIS management: the application must have net.tcp protocol enabled in its properties, as well as the site must have bindings for that protocol configured. If you have large number of services you can use my simplistic C# program which parses the IIS global configuration file —
applicationHist.config. Link to my OneDrive
- If this is first try of enabling the net.tcp protocol, run the following tools to ensure the components of the .NET Framework are correctly set up:
c:\Windows\Microsoft.NET\Framework\v4.0.30319\aspnet_regiis.exe -i and
c:\Windows\Microsoft.NET\Framework\v4.0.30319\servicemodelreg.exe -ia. Use
Framework64 for 64 bit system.
- Make sure that you are not running on the default endpoint configuration. The default configuration can be recognized in the WSDL of the service. It contains
<msf:protectionlevel>EncryptAndSign</msf:protectionlevel> code which is responsible for default authorization settings. These defaults manifest themsevles in a strange symptom of the service working in Test Client and not working in target client application. It is caused by Test Client having successfully recognized default binding configuration from WSDL whereas the target application uses your custom configuration and it is very likely these two do not match.
- Check for the equality of the service names in an
.svc file and in the
Web.config file (assuming that declarative binding is used instead of programmatically created one) in section
<system.serviceModel> -> <services> -> <service>
- Make sure that IIS has created a virtual directory for the application. Create it from Visual Studio by pressing appropriate button in the application’s properties.
For me it has been kind of unexpected behavior. When I update NuGet package, I get newest Entity Framework binaries. Today it is version 5.0. However, default MVC template targets .NET version 4.0. Newest version of Entity Framework for .NET 4.0 is 4.4. The NuGet package contains both assemblies, but the project will use 4.4 because the project targets .NET 4.0 by default. Furthermore, simply changing target runtime version in project properties is not enough. What finally has worked for me was manually editing
.csproj file. I located assembly reference in XML and changed path in
HintPath tag from
\lib\net45\EntityFramework.dll. The conclusion is to pay close attention to what particular version of assembly is actually being referenced and not relying only on NuGet versioning.