We have an Asp.net Core Project with a XUnit Test-Project. Since some Time, I think since updating to Asp.Net Core 2.1, we get the following Warning:
This Warning pops up every time we open the Solution in a new Branch and I have no clue how to get rid of it. Since both, the "Add" and the "Cancel" have no impact on the project.
Some more Data about the project:
.net Core 2.1
Xunit 2.4.0
TFS 2017
Visual Studio 15.8.6
Based on the error message seems the packages folder which contains the *.dlls or the test project is not mapped to the workspace.
Generally you need to map your workspace at the Project level. Please refer to this article on how to set up the source control folder structure.
Related
I have a project ("Project1") that has a reference to an Assembly that I created in another project ("Project2").
I just added a function to a class in that assembly, but that function required me to add the NuGet package System.Drawing.Common. Which isn't an issue.
Here's the issue:
When I build Project1, it does not bring System.Drawing.Common.DLL to the bin folder. So, at runtime, when I execute this new function, I get an error stating that it can't find this DLL.
Is there a way that I can have Project1 bring along all of the Assembly's dependencies? Or do I have to instead add all the same NuGet packages that Project2/Assembly uses to Project1?
I'd prefer the former. I'm using ASP.NET Core 2.2 and Visual Studio 2017.
Thank you.
The build command with .NET Core 2.2 does not bring in the dependencies by default this is for testing only. If you are wanting all the dependency .dll to be included for deployment you should use the publish command to get all the .dll from your NuGet packages. There are other switches to include the framework as well so you don't need to install the framework, on the host.
As a friendly reminder, Dot Net Core 2.2 support will end on December 23, 2019
I know VS 2017 is only RC but there seem to be some major issues with migrating an ASP.Net Core 1.0 project to 1.1. The migration tool fails converting 2 of my 8 projects in the solution (I prefer to adopt a layered architectural approach for my projects) the sample project is located here. One project in particular is the class library I moved my web api controller methods into. In trying to re-create this class library it doesn't seem one is able to declare a controller class after installing Microsoft.AspNetCore.Mvc nuget. It is installed but the compiler is not finding the Controller, RouteAttribute classes, etc. The same issue occured with trying to setup a DI layer IServiceCollection. Nuget Microsoft.Extensions.DependencyInjection doesn't seem to be doing it.
The migration log quite honestly isn't really helping me. It seems to indicate an issue with my service project and the project.json file but as you can tell it is in the repository.
It feels like Microsoft is forcing us down the path of cramming all the "web" stuff into a single project file. Maybe these tools aren't far enough along yet but an RC would indicate they should be closer to ship ready?
ReciPiBook.Api
Message
src\ReciPiBook.Api\ReciPiBook.Api.xproj: Failed to migrate XProj project ReciPiBook.Api. 'dotnet migrate -s -p "C:\Users\xxx\Documents\Visual Studio 2015\Projects\ReciPiBook2017\ReciPiBookCore\src\ReciPiBook.Api" -x "C:\Users\xxx\Documents\Visual Studio 2015\Projects\ReciPiBook2017\ReciPiBookCore\src\ReciPiBook.Api\ReciPiBook.Api.xproj"' exited with error code 1.
src\ReciPiBook.Api\ReciPiBook.Api.xproj: Could not find file 'C:\Users\xxx\Documents\Visual Studio 2015\Projects\ReciPiBook2017\ReciPiBookCore\src\ReciPiBook.Services\project.json'. Migration failed.
src\ReciPiBook.Api\ReciPiBook.Api.xproj: Backing up C:\Users\xxx\Documents\Visual Studio 2015\Projects\ReciPiBook2017\ReciPiBookCore\src\ReciPiBook.Api\ReciPiBook.Api.xproj to C:\Users\xxx\Documents\Visual Studio 2015\Projects\ReciPiBook2017\ReciPiBookCore\Backup\src\ReciPiBook.Api\ReciPiBook.Api.xproj.
src\ReciPiBook.Api\project.json: Backing up C:\Users\xxx\Documents\Visual Studio 2015\Projects\ReciPiBook2017\ReciPiBookCore\src\ReciPiBook.Api\project.json to C:\Users\xxx\Documents\Visual Studio 2015\Projects\ReciPiBook2017\ReciPiBookCore\Backup\src\ReciPiBook.Api\project.json.
I can't directly speak to VS2017 as I'm staying away from it as even though it's a RC, the core tooling is in ALPHA. The VS 2015 core tooling is at least in a "RC" state (actually only preview).
In VS2015 I migrated from 1.0.x to 1.1 manually (per https://blogs.msdn.microsoft.com/dotnet/2016/11/16/announcing-net-core-1-1/):
Download the 1.1 sdk
Change your global.json "sdk":{"version": "1.0.0-preview2-1-003177"} (yes it's a different version string).
Update all the project.json package versions from 1.0 to 1.1 (some are preview some arn't). Just open up the nuget package manager, allow preview versions, then install all the updates.
Fix any of your project.json tool entries as the package manager clobbers those.
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).
I am using .NET Core 1.0 and Visual Studio 2015 Update 3 to make a simple Asp.Net Core MVC website.
How can I debug my application and "Step Into" the .NET Core source code that is available on GitHub?
Specifically, I am trying to troubleshoot one issue with Microsoft.AspNetCore.Authentication.Facebook 1.0.0 assembly that I fetched from NuGet.
I wrote this article more than 1 year ago so it's a bit out of date but the idea is still the same:
You sync to the correct tag from GitHub. In your case, you probably want to sync to tag 1.0.0
Build that repository by running build.cmd or build.sh
Add the src folder path to your app's global.json file. For example, if you cloned Security in D:\Security, then you add D:/Security/src to global.json in the projects property.
Rebuild everything and it should work.
PS: If you use VS and don't see immediately the new code, try restarting it. It's a known issue that sometimes it doesn't pick up the changes to global.json
Update to fit new VS 2017
In Visual Studio 2017 15.3.5 and later
We can use SourceLink support for debugging .NET Core and ASP.NET Core sources.
To enable source link support just Disable Enable Just My Code and and Enable Enable Source Link Support.
Then Enable Microsoft symbol servers.
Victors answers works well with vs 2015.For some one who is looking for a solution with vs 2017,
In vs 2017 there is no global.json availble.So instead of adding folder path in global.json a project reference has to be added and rebuild.
All the others mentioned in Victors article works same as with 2015.
It is important that the git hub tag and the nuget package matches have the same versions.
Also make sure that on a solution level, you have your project "configration", set to debug. See screenshot. .
.
(For the solution properties to show up, right click on the .sln in the solution explorer.)
If you have debugged an app before with the previous version of .NET, delete the %TEMP%/SymbolCache directory as it can have old PDBs that are out of date. Per Debug .NET and ASP.NET Core source code
Background
We have a C++ solution that has been moved from VS2005 to VS2010 where the project files were targeting the .net framework 3.5 but since moving over to VS2010, all of the project files were showing that they were targeting the.net framework 4.0. I have since changed the .vcxproj files manually so that they are targeting the .net framework 3.5, using the method described in the Community Content on this link
The Problem
When I build these project files, manually or via an automated build, the output assemblies are still targeting the .net framework 4.0. I can tell this by using various methods described here. I also know that this is the case as I build and run the installer for this application. Once the application has been installed (which then shows as a service), I try to start the service on the target machine. This service will not start on a machine without the .net framework 4.0 installed. If 4.0 is then installed, the service will start, so this is another test that I can run that shows me that the application has a dependency on .net framework 4.0 which it should not.
The Aim
Ideally, I need to build this application so that the outputs are targeting the .net framework 3.5 instead of 4.0 so that it will actually run as it is supposed to! I have tried to use the 3.5 version of MSBuild as described in one of the answers given for this question here but got the same error that is described underneath that post.
Can anyone help with this? It's proving to be a right pain and I've been banging my head against the wall for over a week trying to get this sorted!
Thanks again in advance
Make sure you follow all the instructions as provided in the first link you posted.
For example,
Make sure you have Visual Studio 2008 installed on the build server.
Make sure you also change each project's "Platform Toolset" to v90.
Verify the project's framework version: "In Solution Explorer, right-click your project and then click Properties. In the Property Pages window, in the left pane, expand Common Properties and then select Framework and References. Verify that the new Framework version appears at the top of the right pane."