I am installing a NuGet Package built from an ASP.NET Core 1.1 class library (embedded view components) into my ASP.NET Core 1.1 web application.
Today the application does not want to load in the project in VS.2017 and giving me this error on the web application project (where I included the NUPKG):
Duplicate linked item found in the project "C:\Users\NAME\.nuget\packages\mypackagetitle\0.0.3\contentFiles\any\netcoreapp1.1\bundleconfig.json
I am puzzled... When I think of it, I do NOT want a bundleconfig.json to be packaged into the NUGET, I only want it to be used for bundlying and minifying the class library prior to building the NUPKG but I do NOT want it included in the NUPKG. I am beginning to think the problem is that because when I look in that folder mentioned above I see bundleconfig.json as part of the included package in both the content\ and contentFiles\ but should be in none of them.
Related
I have created a asp.net core 2.2 web app and I want to integrate TinyMCE in it. I found out that you can download it as a nuget package but when I installed it, the package did not come with the TinyMCE js template folder(It just said that the package was installed and that's it). How can I install TinyMCE properly?
NuGet does not support copying content files to your project directory any more. This was changed when PackageReference was introduced which is the new default and only supported way to include package references in .NET Core projects.
So while TinyMCE still updates the NuGet package, you will only be able to consume it properly in classic non-Core ASP.NET MVC projects on the .NET Framework.
If you want to use TinyMCE in ASP.NET Core, you should look at other mechanisms to include JavaScript dependencies in your application.
When you take a look at TinyMCE’s “Get TinyMCE” page, you will see a few options. If you already have some npm-based deployment set up, then you should probably get it from npm. Otherwise, you can also just download a static release and copy it into your wwwroot directory. This would actuallly have the same effect as using the NuGet package (if that worked).
I am working on a .net core web application with razor pages.
My application structure is like :
DemoCoreApplication with class Libraries "BLL.Data" and "BLL".
In BLL.Data, I have made the DB context then I have added the reference of "BLL. Data" project into my main project i.e: DemoCoreApplication.
Refrences in BLL.Data class library:
After building the main project (DemoCoreApplication), I got some strange version conflicting errors.
I believe the following steps will solve your problem
Install .Net Core 2.2 SDK (if you don't have)
Convert all projects in the solution to use .Net Core 2.2
Rebuild, Start the project
I am having a weird situation where I cannot publish my final Web project. Here is the project structure:
Foo.Services.Common: this is shared library: .NET Standard 2.0.3, Microsoft.AspNetCore.Mvc.Core 2.1.0 with the class DefaultWebSettings defined.
Foo.Services.Common.Razor: Razor Class Library, has reference back to Foo.Services.Common and uses DefaultWebSettings: NETStandard.Library 2.0.3, Microsoft.AspNetCore.Mvc 2.1.0 and some other ASP.NET Core related package (static files, Configuration)
Foo.Services.Api: ASP.NET Core API only (no View, no Razor), has reference back to Foo.Services.Common. Publish well. Uses: Microsoft.AspNetCore.App 2.1.0, Microsoft.NETCore.App 2.1.0.
Foo.Services.Web: front end project. This one is the one I cannot publish! This one has references to both Common projects. Uses: Microsoft.AspNetCore.App 2.1.0, Microsoft.NETCore.App 2.1.0
However, upon publish, this one shows up:
The type or namespace name 'DefaultWebSettings' could not be found
(are you missing a using directive or an assembly reference?)
The error location is in a file of Foo.Services.Common.Razor project, NOT the Web project.
Funnily, Visual Studio perfectly works even with IntelliSense and Go to Definition:
I can build in both Debug/Release mode, run with/without debug any project in the solution well. Moreover, publishing Foo.Services.Common.Razor works without any problem!
In short: I cannot publish my Web project and have no idea what is the problem. I have tried:
Clean/Build.
Delete/Re-add references.
Manually delete all obj and bin folders.
Please show me what I may missing.
In the end, I had to remove Reference of the Common from Common.Razor and Web projects. I guess they could not build because of some conflict between .NET Standard and .NET Core. Had to copy all code of Common into Common.Razor.
I have extracted most of the Database related code from an ASP.NET Core Web Application project with Individual User Accounts, ie. Identity into an ASP.NET Class Library project. I am now stuck in the final pieces which is to remove the concrete assignment to EF Core and moving the connection strings to the Data project.
Here is what I have done so far:
Created a blank solution
Created an ASP.NET Core web
application (TestPatterns.Web) with Individual User Accounts
Updated all the Nuget packages
Created a Class Library Core
package
In the Class Library Project (TestPatterns.Data) Nuget ->
Removed the NetStandard Library 1.6, replaced with
Microsoft.NetCore.App 1.1.0
In the Class Library Project (TestPatterns.Data), added all the EF and
Identity Nuget Packages
Moved over of the 'Data' folder from the
Web application to the class library project
Moved over the
ApplicationUser.cs file from the Web Application to the class
library project folder Models
I end up with a structure like this:
To run a migration I execute the following on the Data project folder:
dotnet ef --startup-project ../TestPatterns2.Web migrations add first
Looking for some help on removing all dependencies of EF Core 1.1 from the Web project and moving the connection strings over. Also, would the DI remain in the Web project or should that move to the Data project also? If so, how?
I am working with .Net Core 1.0 (running under the .Net Framework 4.6.1, non-portable).
I need to include some DLLs that are from a locally-built GitHub project. When I build those projects, and then attempt to "Add Reference" to the resulting DLLs, I get a message saying I can't add them to a Core project directly.
After more research, I found a lot of information regarding "private" NuGet packages. However, those seem overly complex / overly engineered.
Is there any way I can do the following:
Without having to go through the headache of creating a private NuGet repository, can I just "add reference" to the built assemblies that are sitting in the bin folder of the NuGet projects I pulled?
I really don't want to have to build a local-only NuGet package. Mostly because I've already wasted too much time on this issue, and because I read this entire concept is about to be scrapped and turned into something else (sounds familiar by now)... such as the Roslyn-based build system on GitHub.
My current state:
Visual Studio Professional 2015
.Net Core 1.0.1
.Net Core 1.0.1 Tooling Preview 2
No, as for now you have to create a nuget package before and restore it via Nuget. You can use a simple folder as NuGet source, so if you put your compiled NuGet package in C:\packages, you can add this as a source to NuGet (while in the NuGet UI, click the settings Icon and add the folder as new source).
This may change with the next release of ASP.NET Core (1.1), as the .NET/ASP.NET Core team is working to move from *.xproj to *.csproj files.
One of the reasons why you need to use nuget is because it can contain multiple targets and project.json allows you to target multiple platforms (i.e. net452 and netcoreapp1.0).