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>
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 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
We are currently in the process of upgrading our projects to the new VS2017 project format. The main reason behind this was converting some libraries from PCL to .NetStandard and being able to use the new built in Nuget Package features that come with the new project format and therefor getting rid of the whole nuget/library reference/dependency issue.
[Edit]
The main reason to migrate all projects in the solution is to prevent problems with not getting correct dependencies in .nupkg when mixing old (still working with .nuspec) and new format projects
The answers to the question How-to migrate Wpf projects to the new VS2017 format helped us a long way in converting the WPF parts of our projects. However, we still have huge amounts of Windows Forms stuff, which can't be replaced or upgraded.
With just converting the project file, adding the proper settings for file dependencies (for *.Designer.cs and *.resx files) we managed to get it to compile.
How can we now declare the project items in a way to make Visual Studio 2017
a) recognize them as either UserControl or Form ?
b) open the WinForms designer tool to edit .cs or Designer.cs files accordingly ?
Any hint towards finding a solution is greatly appreciated.
I don't believe the SDK style projects have support for the various designers yet. While you can get the nested files to work with DependentUpon attributes, that's as far as it'll get.
That said, if your primary aim is to use the new NuGet features and use the transitive NuGet references, the existing project system supports this now.
Just remove all of your nuget packages manually then delete the packages.config file. You may then have to set <RestoreProjectStyle>PackageReference</RestoreProjectStyle>in your csproj. When you do that, the legacy project type should now use PackageReference NuGet references and do transitive restores.
Note that only packages are transitive this way, project-to-project references are not, so you'll need p2p refs the same as you did before.
Following the release of .NET Core 3.0, the WinForms is now supported but the designer support is currently scheduled for Q4 2020 and can be previewed using Visual Studio 16.4 Preview 3 or later, you have to set the Tools->Options->Preview Features->Use the Preview of Windows Forms designer for .NET Core apps checkbox for this to be enabled.
SDK-style projects should be setup as follows...
<ProjectSdk="Microsoft.NET.Sdk.WindowsDesktop">
<PropertyGroup>
<OutputType>WinExe</OutputType>
<TargetFramework>netcoreapp3.0</TargetFramework>
<UseWindowsForms>true</UseWindowsForms>
</PropertyGroup>
</Project>
Before starting suggest you run the Portability Analyzer against the project since there are some known differences/incompatibilities. There is also another tool called try-convert which will attempt to convert your project.
I want to simplify my configuration in my ASP.NET Core Web Application (.NET Framework) application using VS 2017.
I already know that my website will be running under Windows/IIS in x64 environment and .NET 4.6.2. There is no chance in the foreseen and unforeseen future for this application to use any other environment from the dev to production.
So, I only need Debug x64 and Release x64 modes only. (AnyCPU and x86 are not needed!), so I went ahead and removed all other configuration from the project.
Now, upon compilation, I am getting the following error:
'C:\Projects\MyProject\My.Website\obj\project.assets.json' doesn't
have a target for '.NETFramework,Version=v4.6.2/win7-x64'.
Ensure you
have restored this project for TargetFramework='net462' and
RuntimeIdentifier='win7-x64'. MD.Website C:\Program Files
(x86)\Microsoft Visual
Studio\2017\Enterprise\MSBuild\Sdks\Microsoft.NET.Sdk\build\Microsoft.NET.Sdk.targets
I am developing on Windows 7, I am not sure how to fix this one. Any idea?
For some reason <TargetFramework> in my .csproj file was singular. I added an "s" and it became "TargetFrameworks", which worked:
<PropertyGroup>
<TargetFrameworks>net462</TargetFrameworks>
<RuntimeIdentifier>win7-x64</RuntimeIdentifier>
</PropertyGroup>
I didn't change my TargetFramework, I ran in the Package Manager Console the command:
dotnet restore
And it worked! (I'm using VS2017 and I'm doing a .net core application pointing to .net framework)
I had manually changed mine from x86 to x64. In this case, just restoring the packages from Visual Studio would not work but closing Visual Studio, deleting the project.assets.json, re-starting Visual Studio and re-building the project worked for me. I left <TargetFramework> singular.
Command line nuget restore ... may also have worked.
I had this issue when trying to publish a dotnetcore console application to a local folder after upgrading it to version 2.0.
After trying all the deleting folders and dotnet restore and making sure all settings in Application and Build were 2_0 to no avail. I realised my publish profile was still targeting 1.1, even though 2.0 was showing as selected when I went into edit the profile, it showed 1.1 in the publish summary. So I re-selected 2.0 in the dropdown and it updated the summary to show 2.0 and it all worked fine.
For some reason <RuntimeIdentifier> in my .csproj file was missing.
Adding it resolved this issue for me:
<PropertyGroup>
<TargetFramework>net472</TargetFramework>
<RuntimeIdentifier>win-x64</RuntimeIdentifier>
<Platforms>AnyCPU;x64</Platforms>
<LangVersion>7.3</LangVersion>
</PropertyGroup>
I have a .net core application pointing to .net framework 4.6.1 in VS2017 which I tried to publish. I changed my platform target from x86 to x64 and started to get this error when I tried to publish again but I didn't have any problems to build. I just opened publish profile settings and everything looked normal (target runtime was win7-x64) but that was enough for my publish to start working properly.
Check the actual publishing profile file of the Publish you are trying to run. In our case, we have a set of projects that have to be shared between Core and regular asp.net, so we target Core 1.1 and set the runtime version to 4.6.1. After running through all of the projects and updating them to target version 4.7, I started getting this error on publish (the actual builds worked fine, as did localhost debugging, it was the publish that was jacked).
Checking the actual "widgets - Web Deploy.pubxml" file, I found this at the bottom:
<_DestinationType>AzureWebSite</_DestinationType>
<TargetFramework>net461</TargetFramework>
<RuntimeIdentifier>win7-x64</RuntimeIdentifier>
</PropertyGroup>
</Project>
As others on this thread have mentioned, simply opening up the property sheet of the publishing profile will show you, in my case, that the framework was targeted to 4.7 (which was accurate per the projects involved but did not reflect the actual value in the file)... I did still need to click the Save button to get the underlying .pubxml file to actually be updated with the correct value. You can probably edit that file manually too, if you feel so inclined.
This one drove me nuts. :)
As Boris pointed out, in my case the problem was in the PublishProfiles.
First, I added the following in my .csproj file (As BluE mentioned in the post above):
<PropertyGroup>
<TargetFramework>net472</TargetFramework>
<RuntimeIdentifier>win-x64</RuntimeIdentifier>
<Platforms>AnyCPU;x64</Platforms>
<LangVersion>7.3</LangVersion>
</PropertyGroup>
and then I opened my PublishProfile
and then click on the Edit link:
and finally in the opening dialog, set the TargetFramework to your project's Framework and the TargetRungime to win-x64 and then click Save!
Thats it!
Now if you try publishing your project using this profile, it should be working perfectly.
Hope it helps someone.
For me moving the PlatformTarget section to the common PropertyGroup fixed the same problem on Azure DevOps build:
Does not work:
<PropertyGroup>
<TargetFramework>net461</TargetFramework>
...
<Platforms>x64</Platforms>
</PropertyGroup>
<PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Debug|x64'">
...
<PlatformTarget>x64</PlatformTarget>
</PropertyGroup>
Works:
<PropertyGroup>
<TargetFramework>net461</TargetFramework>
...
<Platforms>x64</Platforms>
<PlatformTarget>x64</PlatformTarget>
</PropertyGroup>
<PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Debug|x64'">
...
</PropertyGroup>
I have several projects in a large solution that won't convert to V4.5.1 (or even V4.5). Most did, but obviously I need to get all of them converted. The GUI in Visual Studio says that it did it and reloads the project, but if you go back into the properties it still says V4 and it won't compile because of dependencies that converted properly and are V4.5.1
I tried manually updating the .csproj files and it says 4.5.1 as the target framework, and I even updated the app.config/web.config to point to the right version, however Visual Studio's property page still says .NET 4 and is throwing compile errors because it can't access the ones that successfully updated to 4.5.1
What am I missing in the process to get these updated? I've tried VS.net 2012 and 2013 and both do the same thing.
In hopes that this helps others:
In our case, the issue was that we were referencing a custom targets file that was created for the entire solution. even though the project was getting updated, the custom targets file was overriding it thus preventing the project from getting updated.
Updated the targets file to point to .net 4.5 and everything was fine.
For me, the solution was to remove all the extraneous <PropertyGroup> sections from the .csproject file - except the first one.
VS 2015 was setting the <TargetFramework> to 4.5.1 on only one of them (not the first one).
After two days of suffering, I have created a new project, targeted .NET 4.5 and then manually copied all files from the existing project. Made sure new project compiles. Removed old project. Moved new project into the directory of the old project so that I can reverse merge into trunk. Job done.
Project I was upgrading was an old WPF project with thousands (no kidding) XAML files in a single project. It also had a release preview of MvvmLight (years old) and an older version of Prism along with a range of other libraries. All and all the project is a mess and somebody must have done something really stupid to make targeting .NET 4.5 this difficult.
I had a similar issue. Turns out the DLLs were built for target framework 4.5.1, but the project I was working in was built for 4.5 only. There were some suppressed warning messages when I compiled. When I showed compile warnings, that was the hint that told me what was going on.
I recompiled the DLLs for framework 4.5, and then the DLLs copied automatically without needing additional references to the assemblies.
In my case I was working with projects designed for SharePoint 2010. Apparently the project template restricts the .NET target framework version which can be selected.
As I was trying to compile a SharePoint 2016 server, once I got the beta templates downloaded for 2016, Visual Studio automatically prompted me to upgrade these projects when trying to open the solution again. Hope this helps someone.
Preview bits for SharePoint 2016 are available here: https://www.microsoft.com/en-us/download/details.aspx?id=49972