This is a .NET 4.62 project within a large solution. We have a mixture of other projects within the solution.
This error occurs when I mark this project as the startup project.
I have a separate .NET Core project within the solution that functions as expected when using the Serilog sink for LogDNA.
I've found very little outside of the standard serilog documentation to help with this issue.
Please let me know if I need to provide additional information.
Thanks.
Related
I spent enough time to find a solution, but did not find it. All the solutions that I found were implemented on .net core.
In general, the task is to write logs from the .net framework mvc project to the elasticsearch
But I could not find suitable solutions for setting up a serilog or another tool
I will be glad for any help
Visual Studio 2019 template for Service Fabric has a drop down to select the dotnet framework. Mine only shows dotnet frameworks and not core. I am able to create other .net core application but not service fabric. Any ideas on what to look for? I have already validated the SDKs are on the computer.
OK, I think I understand what is happening. The first thing the template creates is the project. Since my development machine's OS is Windows, it requires me to use .Net framework. Once inside the project I am able to create individual .Net Core Applications. I haven't been able to find documentation that explains this. I was initially following this tutorial which seemed a little out of date or for some other reason was missing the step for setting up the projects framework version. I don't know how the projects framework is used in either case.
Actually, I'm working on developping an SQL project using visual studio 2019 within framework 4.8 . this project contains three dependencies (sub projects ) referenced as dll into my main sql project. one of them is a serilog project. So, i v generated all the solution and it s ok. but when i tried to create an assembly in sql server, i couldn't create it. i recieve a message shown below:enter image description here
can anyone help me resolve this issues.
thanks a lot
The error message is very clear: The Serilog assemblies reference a different assembly Microsoft.Extensions.Configuration.Abstractions, Version=2.0.0.0 which has not been added to SQL Server yet... So you need to add Microsoft.Extensions.Configuration.Abstractions to SQL Server first, before adding the Serilog assemblies.
This issue is exactly as described in the title.
I have a portable F# class library. I have created an ASP.NET Core Web Application (both .NET Framework and .NET Core), from which I have tried to add a reference to my F# class library.
Trying to add the reference gives a message:
The following projects are not supported as references:
Project type is unsupported by current project and can not (sic) be referenced.
This is extremely disappointing, as the .NET Core is now in General Availability.
Are there any workarounds while this bug gets addressed?
I have a project, which I started with Beta8 bits of .net core and since then I have an F# library, which I use from an asp.net core C# app. (btw here is an RC2 based minimal sample for referencing the F# lib from a net core based console app)
Here is how I did it:
Currently (according to my knowledge) there is no template in VS to create a coreCLR based F# library (the PLC templates under F# are all Full framework based, but that you still cannot reference from asp.net core even if it runs on full framework), so you have to do this with the command line. This is done by:
dotnet new --lang F#
This creates you a hello world coreCLR F# app. You can turn the app into a class library by modifying project.json file.
If you have a VS solution and you click to “Add” -> “Existing project” you can select the project.json file. This way you add it to your solution (and btw. an xproj file will be also created).
So at this point you will have the coreCLR based F# project in your solution. I believe by right clicking the asp.net core project and go to “Add” -> “Reference” -> Projects->Solutions and selecting the F# library you can already reference it. If this does not work, you can do it manually: just list the F# project under the “dependencies” in the project.json of the asp.net core application.
If your asp.net core app runs on full framework still need to do these steps. It actually doesn't really matter.
Now the bad part:
In the RTM (released on Monday) the “dotnet new” command creates an uncompliable F# app, because of some dependency issues. This is tracked here (the title says "on macOS", but it's the same on Windows) and as soon as it’s solved this should be fine (or if you did not yet install RTM and you have RC2 you are also good).
Intellisense and debugging across F# and C# does not work (I posted it here)
Although .NET Core has officially been released, the vast majority of the nuget packages in the ASP.NET Core Web Application are in prerelease. Moreover, although the entity framework identity model has been cleaned up, my attempt to change the key columns for users and roles from strings to ints generated an obscure error when I tried to implement Entity Framework migrations. I know I can do it for a .NET Web Application, even though the process is clunky in places. So for now I have gone back to using a .NET Framework Web Application. I'm looking forward to seeing a fully mature version of ASP.NET Core Web Applications. It's not ready, but it looks very promising.
We are in the middle of development for a core ASP.NET MVC web project and a customer plugin in the form of an MvcContrib plugin web project -- a web project injected into the core web as an area. The plugin is a soft reference in the core project, so it can be developed completely separately and dropped in.
I am trying to generate a way to debug/code the plugin, so that the multiple custom plugins can be developed independent of the core web.
The developers should only have to worry about coding and testing the plugin code. Also, I don't want them to change the core code in this custom plugin project -- that should be done in the core anyway.
I created the core web as a NuGet package and included all the necessary files so I could include it in a web.
My thinking was that I could create an empty web, install my core web, and the developers could have an F5-driven debugging environment.
I tested by creating a blank Mvc project, installed my core package and included one of my plugins. I changed the namespace of this empty web app to the namespace of the core web, thinking that Visual Studio debugging would properly attach and my core assembly.
Simple VS debugging in the empty app does not work -- I receive an HTTP Exception, most likely due to my routes not being registered. I also see that my log4net is not creating its logs folder, so I know the assembly's app start is not being called.
So I see that VS is not attaching to and calling my core assembly.
Can I use this empty web as a host project for my nuget installed web and debug? If so, what configuration am I missing?
If not, how can I include the core web in each customer plugin project in such a way that I can drop my DLL into the bin and debug it?
Using:
Visual Studio 2010
ASP.NET MVC2
The way we are doing things that works pretty well is to use a combination of Web Activator and Razor Generator (available as a Visual Studio extension). In order to access the views within the core web application, the consuming client application needs to know about them, either because they are all included as file references inside the Nuget package (messy) or because they are compiled into the core web dll. You can do that using Razor Generator. Once installed via Nuget you would need to change the Custom Tool property for each .cshtml file to RazorGenerator, which will create a .generated.cs file for each view. This will allow your sample client to use the layout and views from the core web application.
David Ebbo has some useful blog posts on Razor Generator
Couple that with Web Activator to create a PostActivationStartMethod that runs your initialisation code (such as initialising Log4Net) and you should be good to go. We've had this running in 2 scenarios - consuming the framework package via Nuget and adding a project reference directly. Debugging was not working for the Nuget package consuming route but we don't include the pdb files in the Nuget package. We can debug when adding a project reference directly though.