We Keep Coding

Why won't my windows service create and write to log file?

I have a windows service (.net 6), I am using Serilog.Extensions.Logging.File to add logging file, when I run exe file it creates a file and works fine, but when I install it as windows service it is not working. In Event log all looks good, if there is any error for service I can see it in event viewer log. (locally and in the server I have the same condition)
I am running under LOCAL SERVICE if that helps. It has Full access.
I have created the logs directory under my application folder.
appsetting.json file content:
"Logging": {
"File": {
"PathFormat": "Logs/log-{Date}.txt",
"fileSizeLimitBytes": 10485760,
"retainedFileCountLimit": 10
}
I checked the similar questions like this: Similar question not helpful for me

There was an issue in server which it was showing current working directory set to application folder but in fact it was saving in the windows folder, after restarting windows, it is solved.

A windows service, when registered and started, is not running from the folder from which you originally registered the service.
Instead, an instance of the service is held and the execution context is under the OS folder where services are held once registered.
Think of it as the "hosting directory" that you know from web-driven services proobably.
You can look up the directory of a service from the cmd with the command below:
sc qc <service name>

Why can't my WebAPI service call find part of the path to a folder via IIS?

I have .NET Core WebAPI 2.1 services. I created a structure in my deployment folder like below. (I'm using IIS.) I want to access MyVariables.json from all services. But, it gave this error:
Could not find a part of the path 'C:\wwwroot\MyProject\Shared\MyVariables.json'.
But that folder and path do exist. I'm trying by this code from my C# service.
using (StreamReader file =File.OpenText(#"../Shared/MyVariables.json"))
{
}
What can be the reason of this?
My publish folder design
-wwwroot
-MyProject
+Service1
+Service2
+Service3
+Service4
-Shared
MyVariables.json

IIS runs with an identity that is configured in the App pool.
Directory access rights must be given to the identity used to run the App pool.
Start inetmgr.exe to configure IIS,find App Pool identity and then configure access in file explorer.
Reference: https://learn.microsoft.com/en-us/iis/manage/configuring-security/application-pool-identities

.NET Core 2.0 connection string for Mac and PC

I've just started working on a .NET Core 2 project. I am using a Mac while the other developers are on Windows PCs. However there are some problems with SQL Server on Mac. First, SQL Server does not run on Mac. That can be worked around by running SQL Server in a local docker container: https://medium.com/#reverentgeek/sql-server-running-on-a-mac-3efafda48861
Second problem is that LocalDB, which is used in most tutorials and for local development/testing does not work for mac either, as stated here Could not resolve host '(localdb)' on Visual Studio for MacOS.
My question is, what is a good way of loading the correct connection string for PC or Mac in Development? I was thinking about adding multiple strings like so but not sure what is best practice.
appsettings.json
"ConnectionStrings": {
"DefaultConnection": "Server=(localdb)\\mssqllocaldb;Database=myWindowsDb;Trusted_Connection=True;MultipleActiveResultSets=true",
"MacConnection": "Server=localhost;Database=myMacDb;User Id = someuser;Password=mySecretMacPassword;Initial Catalog = myMacDb;"
},

Since this is just for your own individual dev environment you shouldn't make any changes to appsettings.json in your project to work around it. Instead, you can create a separate appsettings.Development.json file containing:
"ConnectionStrings": {
"DefaultConnection": "Server=localhost;Database=myMacDb;User Id = someuser;Password=mySecretMacPassword;Initial Catalog = myMacDb;"
}
And ASP.NET Core will load it by default after appsettings.json and override and previous values read in. I would keep this file out of source control and use it for individual developer settings.

Problems with deploy ASP.NET 5 (ASP.NET Core) app to Azure

I have an app on ASP.NET 5 (CoreCLR) and I try to publish it to the Microsoft Azure. I using free Web App (not VDS)
I am publishing app using Visual Studio 2015 Publish->Microsoft Azureand following this instructions.
But when I publish it and try to open, I see just non-stop loading of empty page. I enabling logging and view the log (stdout.log) from Azure and there was only:
'"dnx.exe"' is not recognized as an internal or external command,
operable program or batch file.
Also I tried to do Continiusly publishing with git. During push, It started restoring packages and failed with error no disk space available.
Is there any way to publish ASP.NET 5 app to the Azure Web App?

Short Answer
But when I publish it and try to open, I see just non-stop loading of empty page.
This happens when our app fails to publish the runtime (dnx.exe) with the application.
Discussion
There are several ways to publish ASP.NET Core rc1 apps to an Azure Web App. These include continuous deployment with Git and publishing with Visual Studio. Post your repository's contents for specific help.
The example is an ASP.NET Core rc1 app, deployed to an Azure Web App, via GitHub continuous deployment. These are the vital files.
app/
wwwroot/
web.config
project.json
startup.cs
.deployment <-- optional: if your app is not in the repo root
global.json <-- optional: if you need dnxcore50 support
app/wwwroot/web.config
Add the HttpPlatformHandler. Configure it to forward all requests to a DNX process. In other words, tell the Azure Web app to use DNX.
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<system.webServer>
<handlers>
<add name="httpPlatformHandler"
path="*" verb="*"
modules="httpPlatformHandler"
resourceType="Unspecified"/>
</handlers>
<httpPlatform
processPath="%DNX_PATH%"
arguments="%DNX_ARGS%"
stdoutLogEnabled="false"
startupTimeLimit="3600"/>
</system.webServer>
</configuration>
app/project.json
Include a dependency on the Kestrel server. Set a web command that will startup Kestrel. Use dnx451 as the target framework. See below for the additional work to target dnxCore50.
{
"dependencies": {
"Microsoft.AspNet.Server.Kestrel": "1.0.0-rc1-final"
},
"commands": {
"web": "Microsoft.AspNet.Server.Kestrel"
},
"frameworks": {
"dnx451": { }
}
}
app/Startup.cs
Include the Configure method. This one adds an extremely simple response handler.
using Microsoft.AspNet.Builder;
using Microsoft.AspNet.Http;
namespace WebNotWar
{
public class Startup
{
public void Configure(IApplicationBuilder app)
{
app.Run(async (context) =>
{
await context.Response.WriteAsync(
"Hello from a minimal ASP.NET Core rc1 Web App.");
});
}
}
}
.deployment (optional)
If your app is not in the repositories root directory, tell the Azure Web App which directory contains the app.
[config]
project = app/
global.json (optional)
If you would like to target .NET Core, tell Azure that we want to target it. After adding this file, we can either replace (or complement) the dnx451 entry in our project.json with dnxCore50.
{
"sdk": {
"version": "1.0.0-rc1-update1",
"runtime": "coreclr",
"architecture": "x64"
}
}

Firstly, yes, you can happily run ASP.Net 5 core apps on Azure, but there are some gotchas.
I don't know why it doesn't work when you publish from Visual Studio itself (so why is he posting an answer I hear you ask...), but here are some things to have a look at;
Try running in IIS locally (rather than kestrel) - just to see if there is a problem. For example, you need a Web.config with some settings or you need the app.UseIISPlatformHandler in startup.cs.
Have a look at your global.json file. It shouldn't matter when you publish from Visual Studio but it won't hurt to set this correctly. You can do something like this:
.
{
"sdk": {
"version": "1.0.0-rc1-update1",
"runtime": "coreclr",
"architecture": "x64"
}
}
Regarding continous publishing - that is a known problem with free and shared sites and one that cost me a few hours. Basically, when you are deploying by this mechanism and you specify corecelr, the entire runtime is re-installed from Nuget and that takes up nearly 1GB (the allowance for free and shared sites). Add a few NPM packages and you are over the limit and, hey presto, you can't deploy. #shanselman discussed it recently on one of his podcasts. It's not actually the runtime binaries that take up all the space, but because we are in build mode, all the documentation XML files are installed as well, because Nuget doesn't know you are not in a development environment, and they are huge.
Right now, the simplest answer if you want to use continuous publishing on a free or shared site is to also include the full runtime in your project.json and set your global.json to use the full CLR instead of the coreclr. Just very frustrating.

I was having the same problem. This answer solved the issue.
When creating a new project with the asp.net core template the global.json file was part of my API project, but it was also referenced in the Solution Items folder. When published to an Azure API app, two global.json files were deployed:
In the /approot/global.json
In the /approot/src/MyAPI/global.json
I moved the global.json file out of the project folder to the solution root, and re-added a reference back into the Solution Items folder.
When deployed only the /approot/global.json file was then deployed, resolving the issue.

Error while publishing Azure WebJob for "staging" enviroment

My Project Configuration:
I have a web application project (Visual Studio 2015 update 1 + c#) that includes an Azure Webjob. The Webjob is part of the project configuration. Looks like this (location: ProjName -> Properties -> webjobs_list.json):
{
"$schema": "http://schemastore.org/schemas/json/webjobs-list.json",
"WebJobs": [
{
"filePath": "../Jobs/XXX/XXX.csproj"
}
]
}
My Azure Configuration:
I created a new website ("Web app") and published (to "production" environment) my project. Working great. Including my webjob.
So far, all good. Now, I created a new environment (within my web app site) that called "Staging". Go back to my Visual studio project, download the newly created publish profile (staging) and publish it.
The Problem
Visual studio refuse to publish my project to the staging environment with this error:
An error occurred while creating the WebJob schedule: No website could
be found which matches the WebSiteName [XXX__stage] and
WebSiteUrl [http://XXX-stage.azurewebsites.net] supplied.
What the...? Why?
By publishing the same project to "Production" environment, it's prove that the project configuration is OK (including webjob).
Any solution for this strange?
Thank you.

There are some known issues with configuring the Azure Scheduler from Visual Studio. The suggested approach is to avoid the use of the Azure Scheduler, and instead use the newer CRON based scheduler feature described in the docs here.
Basically, you create the WebJobs as manual (not scheduled), and then add a settings.job to it with a CRON expression, e.g. to run every 15 minutes:
{
"schedule": "0 */15 * * * *"
}
Going forward, this will be the default in VS.