How to enable trace.axd in ASP.NET core? - asp.net-core

Our app is based on ASP.NET Core 2.0. It works fine in development environment but we see an oauth error when published to production.
All the documentation on asp.net core seems to point to using ILoggingxxx interfaces. The examples I found typically call logging.AddConsole() method so that the log lines can be viewed in VIsual Studio debug window. I am wondering if the good old trace.axd is still available under asp.net core. If so, I would appreciate the steps to enable tracing. Regards.

trace.axd is exclusive to applications based on .NET Framework and ASP.NET 4.x. It is not available in ASP.NET Core applications at all.

Related

Migration of ASP.NET 4.6 Help Pages to .NET 6 (.net core)

In .NET framework we have support of Creating Help Page for Web API.
https://learn.microsoft.com/en-us/aspnet/web-api/overview/getting-started-with-aspnet-web-api/creating-api-help-pages
Does this feature supported in .NET 6. We are migrating our legacy ASP.NET framework application to .NET6.
How to migrate this feature to .NET6? If it is not supported in .Net6(.net core) how can we achieve the similar functionality in .Net core
I am trying to migrate this feature to .net core but I am facing issues on how to load the app data, register HelpdataConfig in .net core.
ITNOA
As you can see in ASP.NET help page for ASP.NET Core Web API, the Microsoft.AspNet.WebApi.HelpPage is for ASP.NET and does not for ASP.NET CORE or .NET 6, so you have to migrate this library to some popular Web API documentation libraries like Swagger
As you can see in ASP.NET Core web API documentation with Swagger / OpenAPI, you can use below documentation
By Christoph Nienaber and Rico Suter
Swagger (OpenAPI) is a language-agnostic specification for describing REST APIs. It allows both computers and humans to understand the capabilities of a REST API without direct access to the source code. Its main goals are to:
Minimize the amount of work needed to connect decoupled services.
Reduce the amount of time needed to accurately document a service.
The two main OpenAPI implementations for .NET are Swashbuckle and NSwag, see:
Getting Started with Swashbuckle
Getting Started with NSwag

Can ASP.NET CORE MVC be hosted in Xamarin App(Android)?

I have a ASP.NET CORE MVC (.NET CORE 3.1) application running well on Kestrel in Windows, Now I'm wondering if possible to migrate it to Android via Xamarin?
The purpose of this move is the lower cost of Android device.
And I noticed: Run ASP.NET Core 3.0 apps with MonoVM
but seems no details?
No, Not yet (Jan 2021).
Xamarin, NetFramework, Net5, NetCore3 all support NetStandard. AspNetCore is based on NetCore, not NetStandard. If AspNetCore was a NetStandard library, it would support it, but AspNetCore uses other libraries in NetCore which do not exist on Xamarin.
By the way, if you need just a simple web server running on android like Kestrel, you can use EmdedIO. Indeed it doesn't support MVC, MVP, and MVVM, so you can not run AspNetCore app on Xamarin:
https://github.com/unosquare/embedio

asp.net webapi core 3.1.self-hosted Kestrel app needs conversion to WIndows service

Have a working self-hosted WebApi exe using Asp.Net Core 3.1 and Kestrel and http. How can I convert that to a Windows service?
It was developed using Visual Studio 2019 Community, and also includes Serilog and Swagger, but uses a third party facilty (Actian OpenROAD Server) rather than a database.
I have searched lots of articles but nothing seems to specifically address this issue. The notes on starting from scratch using a "Worker" also do not help much and are mostly aimed at running background tasks for MVC.
Sorry but I have searched recent questions under various tags and cannot find a suitable answer.

ASP.NET Core Web Application Template for VB.NET

I know that for some reason VB.NET was not supported in the first release of Core, but this is meant to be fixed in 2.0...
Can someone tell me where they hide the ASP.NET Core Web Application template? It's there for C# but is missing for VB.NET
VS version 15.3.4
.NET Core 2.0 SDK has been installed
Thank you
As far as I know, Asp.Net Core doesn't support VB.Net in .Net Core. you can see detailed information from the following a link https://github.com/dotnet/cli/issues/587

Why use the full .NET Framework with ASP.NET Core?

With ASP.NET Core 1.0 release one can run on either .NET Core or the full .NET Framework per the documentation here. I'm trying to understand the latter option of why one would select ASP.NET Core + the full .NET Framework?
I understand the difference between the full .NET Framework and .NET Core. However, if I wanted to use the full .NET Framework, why not just use ASP.NET 4.6? I thought the idea was a 1-2 punch with ASP.NET Core atop of .NET Core allowing the slew of benefits like cross platform deployment, modularization, ability to deploy to a Docker container, performance, etc. Without .NET Core I don't believe anything on that list is still valid, so what is the use case for the full .NET framework + ASP.NET Core? What does ASP.NET Core on it's own still provide to me without .NET Core?
.NET Core allowing the slew of benefits like cross platform deployment, modularization, ability to deploy to a Docker container, performance, etc.. Without .NET Core I don't believe anything on that list is still valid
The only benefit you don't have if you choose the full .NET framework over .NET Core is being cross platform. All the other benefits of deployment, modularization, docker, performance, etc... are still valid.
We actually run our ASP.NET Core web app on the full framework and now we enjoy the benefits of having Dependency Injection as a 1st class citizen, having NuGet built in, having an lean HTTP request pipeline which makes our performance better, open sourced (so all the issues can be solved by a short visit to GitHub), modularity (still have to come across something we couldn't customize to our own needs after almost a year now), and so on. And we know we don't need to deploy on any other OS than Windows, so we can still have all the benefits of the full framework.
Update from Tseng
Well, you can still target full .NET Framework under Linux for example. There you need mono 4.6 installed there. There are some limitations as not all classes are implemented in mono, but a majority is and around the corner case (i.e. encryption) you have to work around
Update from atconway
It's also worth noting at the time VB.NET is not supported by .NET Core if that's a requirement.
However, if I wanted to use the full .NET Framework, why not just use ASP.NET 4.6?
If I use ASP.NET 4.6 instead of ASP.NET Core 1, then I won't be able to use ASP.NET Core MVC. None of the features on that documentation page would be made available to me! I would have to build an MVC5 application. Boooo!
I'm trying to understand the latter option of why one would select ASP.NET Core + the full .NET Framework?
I'm assuming that another way to ask this would be: "why would you take the red path when you can take the brown path?"
One argument for doing it this way is deployment. If you've got a bunch of existing Windows servers with IIS on them, you're going to need to install additional software on each of them and set them up to run Core applications. IIS just becomes a reverse proxy for your .NET Core app.
However, if these apps were built on the .Net Framework instead, you wouldn't have to do this. You could still use web deploy (for example) to move them onto the servers. Maybe you've got some other existing IIS configuration settings that you don't want to migrate.
Using ASP.NET Core 1.0 targeting the .Net Framework, you can get the benefit of the new features in ASP.NET Core MVC without having to change your existing infrastructure.
One important benefit of using Full .NET framework with Asp.Net core is availability of mature libraries and frameworks that are developed mainly to target previous version of .NET.
But by passing of time and implementing more and more libraries to target .NET core and developing more features for .NET core itself this benefit may fade out.
Having to leverage legacy technologies like OLE DB that will never be implemented in NET Core System.Data is another reason.
One thing to consider is that it can be a migration path. Say, for example, you have an existing ASP.NET 4.6 application that you intend to migrate to .NET Core. You want to take advantage of ASP.NET Core features like TagHelpers, Dependency Injection, etc., but you aren't ready or able to use .NET Core framework. So, you develop the ASP.NET Core application, targeting just the .NET full framework. Then, you take the next step and multi-target, going for both .NET full framework and .NET Core framework. This gives you the flexibility to easily deploy to IIS with the full framework or cross-platform with the core framework. From there, you can decide if you want to eliminate the full framework or not.