I have a really strange problem. If I create a .NET Core console app and change the target framework to .NET 4.6.2, I get the typical "your breakpoint will not currently be hit" warning, and indeed breakpoints are never hit. So basically:
Create a Console App (.NET Core) using VS2017.
Add a breakpoint somewhere.
Debug it. The breakpoint is hit.
Change the <TargetFramework> from netcoreapp2.0 to net462 in the .csproj.
Debug it (with breakpoint still there). The breakpoint is not hit.
I can consistently reproduce this on my machine, but a colleague of mine is following the same steps and not getting this on his machine.
I've tried all sorts of suggestions on Stack Overflow for dealing with typical "breakpoint will not be hit" scenarios, restarted VS, re-cloned the repo from scratch, restarted the whole machine, banged my head against the wall, and nothing worked.
So, I seem to have a problem specifically when retargeting an app, but it's strange that it didn't happen on a colleague's machine. Any idea what could be my problem?
I had the exact same problem with net471 and you can solve it by targeting both frameworks: core framework and full .net framework in csproj file.
After that, the breakpoint is hit again and you can use the full .net framework and core .net packages.
If your project allows targeting multiple frameworks, this should help.
<PropertyGroup>
<OutputType>Exe</OutputType>
<TargetFrameworks>netcoreapp2.0; net471</TargetFrameworks>
</PropertyGroup>
I found the answer that solves a problem without targeting both frameworks:
https://stackoverflow.com/a/18738954/5532339
Related
I was following a tutorial on Pluralsight about having an MSTest project target both .net core 2.2 AND .NET 4.7.2. This required going to my .csproj file for my test project and editing it so that the following:
<PropertyGroup>
<TargetFramework>netcoreapp2.2</TargetFramework>
...
would change to become TargetFrameworks (that's plural now) and then we add in the .NET 4.7.2 moniker, as follows:
<PropertyGroup>
<TargetFrameworks>netcoreapp2.2;net472</TargetFrameworks>
...
As soon as I saved the .csproj file, VS 2019 showed the following error in a yellow bar at the top:
The project ran into a problem during the last operation: The value of
the 'TargetFrameworkMoniker' and 'NuGetTargetMoniker' properties in
the 'Debug|AnyCPU' configuration are both empty. This configuration
will not contribute to NuGet restore, which may result in restore and
build errors.
What am I doing wrong?
For me, the error went away when I closed Visual Studio and opened the solution again
With Visual Studio closed, removing the .vs folder in the solution root solved it for me.
I just face this problem for .net core where SDK version was specified as "3.0.103". I just change it to my PC installed .net core version "3.1.300" in global.json file. It worked.
I was stuck with the Error. I eventually solved it by upgrading Visual Studio. I upgraded from 17.3.0 to 17.3.1
After a fair amount of searching, the best answer I could find was this one which is technically for a different error, but talks about having to make the web.config or app.config NOT read-only.
Since I had downloaded a sample solution from an external source, not only did I have read-only files, but my computer had "blocked" the .sln and .csproj files. Once I made all the files non-read-only and "unblocked" the .sln and .csproj files, everything started magically working.
Sounds like a silly thing but I fixed this by updating one of my namespace references - previously I had from a previous class and had not updated properly.
I tried closing out of all VS instances, I was already on the latest version of VS 2022, so I did a repair and restarted my computer and its now working.
I'm still not quite sure what was wrong as this solution was working just a few hours earlier and I had changed nothing.
I too was stuck with the Error. I eventually solved it by upgrading Visual Studio. I upgraded from 17.4.0 to 17.4.2.
¯_(ツ)_/¯
I'm new to .NET Core. I've published a self-contained version of a test program which runs a simple TCP server, to linux-x64. However, when I publish it, the result is 70MB of the whole SDK. I can remove many of them, and their references within *.deps.json, without the program falling over, so I feel there's a lot of unused references. Is there a tool, or a different method of deployment, which is leaner?
The reason for this is I would like to have an alternate deployment method for a board with only 60MB space - removing Mono and using a native .NET Core program would fit the bill nicely.
Thank you.
Edit: This question is not a duplicate as Resharper's "Optimise References" is unavailable on .NET Core projects. Also, the other VS Extensions only seem to work up to VS2011.
Edit2: I've solved the problem, using .NET Core's ILLinker.
Far as I know, there is no standard solution for it. But there are some solution!
The first is the Visual Studio Extension, which is removed the not used references, it called Reference Assistant And the second one is the ReSharper. The Resgharper is complex extension which has this functionality and many others.
And here is the littel decsription how the resharper works: Remove Unused References With Reshaprer
I found the solution to my problem: using ILLinker and the instructions provided here.
It removes not only unused DLL's, but dead code within those DLL's. Initially I didn't get it working, but that article worked.
Not removing packages but unused code: within .NET Core 3.1 you can use the -p:PublishTrimmed=true argument with your publish command:
dotnet publish --configuration Release --runtime win81-x64 -p:PublishTrimmed=true
In my case this significantly reduced (about a third) the size of the publish folder.
Information can be found here: https://github.com/mono/linker/blob/master/docs/illink-tasks.md
But note their warning you see in the output: Optimizing assemblies for size, which may change the behavior of the app. Be sure to test after publishing. See: https://aka.ms/dotnet-illink
I created a fresh Xamarin Forms solution, upgraded all the NuGets, made sure that the UWP version was targeting build 16299, and made sure the .NET Standard project is targeting 2.0. I ran the project and was able to debug the .NET Standard 2.0 DLL fine. You can download this here but I don't think it will be of any use: https://www.dropbox.com/s/jw13heu98yq2n6x/CleanXF.7z?dl=0.
I then pulled these projects in to another solution, added some references to other projects, and copied and pasted some Xamarin Forms pages etc. in to the new clean projects. I could then compile and run the project, but debugging the .NET Standard 2.0 Xamarin Forms project does not work at all. Debugging the UWP code does work, and the lower level .NET Standard 2.0 projects do debug. It's only one project that won't debug. I have already tried Git cleaning the folders again and again to ensure that rebuilds are happening. I have also tried creating the project from scratch and adding all the files back in. Again, it compiles and runs, but doesn't debug.
What things can I try to get debugging working?
It turns out that there are still issues with debugging .NET Standard 2.0 assemblies in UWP. Apparently there is a new type of PDB that is generated in .NET Standard 2.0 projects. This is related to this bug which has a workaround:
https://github.com/dotnet/sdk/issues/955
It's just a matter of editing the .NET Standard 2.0 project like so:
<PropertyGroup>
<DebugType>pdbonly</DebugType>
</PropertyGroup>
This switches to old school PDBs and will slow down debugging, but until MSBuild etc. catches up, it's the only way to solve the problem from what I can see.
Edit: Microsoft claim that the original bug is now fixed in the latest version of Visual Studio, but I have not confirmed this:
https://github.com/Microsoft/UWPCommunityToolkit/issues/1951
Some people are still experiencing this issue - even people at Microsoft, so I don't know the status of this at the moment.
alternative solution to accepted solution, you use also below lines. it tells that use full debugging, symbols included only for debug mode. I am not sure if Melbourne developers answer is affecting release mode, just to ensure.
<PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Debug|AnyCPU'">
<DebugType>full</DebugType>
<DebugSymbols>true</DebugSymbols>
</PropertyGroup>
I have a self-written .NET Framework 4.6.2 application (call it Player) dynamically loading self-written .NET Core 2.0 DLLs (call them Game-DLLs). Now I would like to enable creators of .NET Core 2.0 Game DLLs to debug into their code. To do this, the .NET Framework 4.6.2 Player application needs to be started with the "Managed (v4.6, v4.5, v4.0) code" Debugger attached. I can do this manually: Start the Player.exe and choose Debug->Attach from VS's menu, select the correct debugger and it works: I can debug into the .NET Core Game DLL.
Visual Studio IDE (v2017) seems to store debug configurations for .NET Core projects in some very new thus very undocumented "launchSettings.json" file. I managed to specify a launchSetting profile to start the Player.exe but I did not find a way to attach the correct debugger. It turns out that starting the debugger with a launchSetting profile will always choose the "Managed (CoreCLR)" debugger. This starts the exe but debugging is disabled because no symbols are loaded and thus breakpoints do not work.
There is very few documentation about the options in launchSettings.json and the little you can find is all about developing ASP.Net.
Does anybodyknow how to specify the debugger in launchSettings.json OR know a good source of documentation for launchSettings.json?
Thank you!
Additional information:
DLLs that reference the .NET 2.0 standard are INDEED compatible and usable among different flavors of .NET, including .NET Core 2.0, .NET Framework 4.6.2, latest Xamarin, and others. As I mentioned above: This already works and is out of question. I can take a DLL written with .NET Core 2.0 and thus obeying to the .NET Standard 2.0 and load it - dynamically with Assembly.LoadFrom or statically referenced - from an executable running on .NET Framework 4.6.2. This works like a charm.
The only thing is: If I want to debug into the .NET Core DLL in this case, I have to manually setup the debugger. I don't understand why Visual Studio 2017 replaced the very elaborate debugger-setup-project-page by some fast-hack with only the ASP.Net use-case in mind.
The funny thing is: I can even setup Visual Studio Code (in its very well documented "launch.json" file) to use the correct debugger and debug the scenario I described with a single click on the green Play button.
Unfortunately the launchSettings.json-schema is not of much use, I already stepped over it. It lists (somehow) the known Attributes but leaves no clue how they are interpreted or what Values are allowed. For example I suspected the sdkVersion Attribute to somehow help me set the .NET Framework 4.2... Debugger, but it says nothing about what this Attribute is good for neither how to specify some sdk...
I have a legacy project that I have inherited. It was an absolute utter and complete mess. Within version control, every single file was revision 1. Long story short it was completely broken and did not come close to compiling. dll refresh files were pointed to files outside of version control, and the dll's that were versioned were the WRONG ones. Hours and hours lost just getting this to build in VS2008.
At any rate, according to the project details the project targets framework 3.5. However, an 401.2 authorization error I get in my browser when debugging the project says that framework 2.0.* was being used.
Has anyone had seen this before, or know of a remedy?
The 3.5 version of the framework is just some additional features (such as Linq) integrated into v2.0 of the CLR. So, even if your project shows a target of 3.5, it is still running on version 2.0 of the CLR.
See http://en.wikipedia.org/wiki/.NET_Framework_version_history#.NET_Framework_3.5
Check IIS to see which version of the framework the worker process is using. Also check any class files you may also be compiling to make sure that they are using the same framework version.