I assume that many would mark this question as duplicate, but let me explain what kind of problem I'm facing right now.
I've just noticed that Console Application in solution has x86 target option, though everything else, e.g. libraries and dependent web site has AnyCPU target.
I've googled other question regarging Configuration Manager and adding new configuration AnyCPU for my Console Application, but here is the problem. I can't create new AnyCPU configuration as I get error, that it's already created:
And here is error creating new configuration with AnyCPU target:
I just don't get it why I can't create this configuration, it isn't listed in dropdown selector for my project.
There is another place where target configuration might be changed, it's project properties' build tab:
and I've set AnyCPU value in platform target, but platform is still x86.
The only way to change platform itself is editing csproj directly:
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|AnyCPU' ">
<PlatformTarget>AnyCPU</PlatformTarget>
<DebugSymbols>true</DebugSymbols>
<DebugType>full</DebugType>
<Optimize>false</Optimize>
<OutputPath>bin\Debug\</OutputPath>
<DefineConstants>DEBUG;TRACE</DefineConstants>
<ErrorReport>prompt</ErrorReport>
<WarningLevel>4</WarningLevel>
</PropertyGroup>
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|AnyCPU' ">
<PlatformTarget>AnyCPU</PlatformTarget>
<DebugType>pdbonly</DebugType>
<Optimize>true</Optimize>
<OutputPath>bin\Release\</OutputPath>
<DefineConstants>TRACE</DefineConstants>
<ErrorReport>prompt</ErrorReport>
<WarningLevel>4</WarningLevel>
</PropertyGroup>
And here we come to my questions:
What's the idea to place target property in two different properties?
Why can't I select AnyCPU for console applications by default? There was opinion that Visual Studio team made this intentionally.
And what possible issues might occur if I change target platform by editing csproj file?
Related
I've noticed that the build time is exponentially slower in my new .NET Core project than in previous projects written in .NET Standard 4. I tried a number of other solutions mentioned on here to no avail.
I had a "eureka" moment and finally tracked down the problem to having enabled nullable reference types in the project (.csproj) file.
<PropertyGroup>
<TargetFramework>net5.0</TargetFramework>
<Nullable>enable</Nullable>
<Configurations>Debug;Release;Stage</Configurations>
</PropertyGroup>
I didn't want to disable the feature but I also don't need my build times taking minutes instead of seconds. To workaround this issue, I added a condition to my .csproj file to set nullability to false when performing a debug build inside Visual Studio:
<PropertyGroup>
<TargetFramework>net5.0</TargetFramework>
<Nullable>enable</Nullable>
<Configurations>Debug;Release;Stage</Configurations>
</PropertyGroup>
<!-- Disable nullable checks on debug build (fixes slow build issue) -->
<Target Name="DisableNullableForVisualStudioBuild"
BeforeTargets="CoreCompile"
Condition="'$(BuildingInsideVisualStudio)' == 'True' And '$(BuildingProject)' == 'True' And '$(Configuration)' == 'Debug'">
<PropertyGroup>
<Nullable>disable</Nullable>
</PropertyGroup>
</Target>
Voila, problem solved! This of course does have the unfortunate side effect of not having the compiler provide me warnings inside the Output panel regarding nullables, but I still get Intellisense warnings in real-time, so for me it's an acceptable compromise.
A developer migrated a csproj file to the newer csproj syntax. The top of the csproj file follows:
<Project DefaultTargets="Build" Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<Configuration Condition=" '$(Configuration)' == '' ">Debug</Configuration>
<Platform Condition=" '$(Platform)' == '' ">x86</Platform>
<ProductVersion>8.0.30703</ProductVersion>
<SchemaVersion>2.0</SchemaVersion>
<ProjectGuid>{4CF6CFA6-13B2-426E-913B-A42BF6642A69}</ProjectGuid>
<TargetFrameworks>net472;netcoreapp3.1</TargetFrameworks>
<RuntimeIdentifiers>win-x64;linux-x64</RuntimeIdentifiers>
Other developers were no longer able to open the two solution files containing this project. Visual studio would begin opening the solution, but the progress bar would hang when it got to this converted project. It should be noted that many other projects had been migrated without this issue.
A blank solution was created and the hanging project was added to this blank solution. This opened without a hang.
Any ideas on what could be done to allow this project to not hang. I suppose a new project could be created as a work around.
I was able to correct the hang by creating a new project GUID and replacing the old project GUID in the csproj and sln files. This allowed the solution to open. I used the Visual Studio GUID tool available in the Visual Studio Tools main menu to create the GUID in registry format.
I want to know how to create a Xamarin.Forms Project that targets minimum version of Android Kitkat (API 19), without using the Shared Project option.
.Net Standard Library is not an option since the minimum supported Android version is Nougat. A large percentage of my target users (more than 40%) still uses phones with an Android version lower than Nougat.
In Visual Studio 15.5.1 or greater, no PCL option is provided under the Code Sharing Strategy Section in creating a new Xamarin.Forms project when using the Cross-Platform App template.
It was noted that PCL is now deprecated on Xamarin's Forum and also on the Visual Studio Developer Community
Key Supporting Questions:
With the latest Vs 2017, is PCL even still possible with Xamarin.Forms? And How?
If Yes, What are the steps to create a PCL-Based Xamarin.Forms Project and are there any open-soured templates to bootstrap this?
If No, Does this mean I can only support Android KitKat with Xamarin.Forms using the Shared-Project Code Sharing strategy/template?
Forms supports Android 4.0.3 (API 15) and higher, you are confusing the "Target Framework" (compileSdkVersion) for the "Target Android Version" ( targetSdkVersion) vs the "Minimum Android Version" (minSdkVersion).
Your Xamarin.Form project has to use the target framework of Nougat/7.0 (MonoAndroid7.0) or above but can target the minimum of 4.0.3/IceCreamSandwich version.
Note: The latest version of Forms required a target framework of 8.0
Xamarin has a great guide that explains how those things relate from Android to Xamarin.Android
Understanding Android API Levels
Microsoft completely removed the template option to create PCL-based libraries
PCL projects still build fine
NetStandard is the only future, PCLs are dead, etc, etc...
IMHO this was breaking change as a lot of my clients are not ready to convert to NetStd and there are still NetStd bugs floating around (edge cases mostly)
Still need to create a PCL library, grab an existing project and copy, strip and rename it... or create the .csproj yourself (see basic .csproj).
A Basic Profile111 PCL .csproj:
<?xml version="1.0" encoding="utf-8"?>
<Project DefaultTargets="Build" ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup>
<Configuration Condition=" '$(Configuration)' == '' ">Debug</Configuration>
<Platform Condition=" '$(Platform)' == '' ">AnyCPU</Platform>
<ProjectGuid>{C38DBA87-39CB-4FD5-B409-6D19E6ED54C8}</ProjectGuid>
<ProjectTypeGuids>{786C830F-07A1-408B-BD7F-6EE04809D6DB};{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}</ProjectTypeGuids>
<UseMSBuildEngine>true</UseMSBuildEngine>
<OutputType>Library</OutputType>
<RootNamespace>PCLTemplate</RootNamespace>
<AssemblyName>PCLTemplate</AssemblyName>
<TargetFrameworkVersion>v4.5</TargetFrameworkVersion>
<TargetFrameworkProfile>Profile111</TargetFrameworkProfile>
</PropertyGroup>
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|AnyCPU' ">
<DebugSymbols>true</DebugSymbols>
<DebugType>full</DebugType>
<Optimize>false</Optimize>
<OutputPath>bin\Debug</OutputPath>
<DefineConstants>DEBUG;</DefineConstants>
<ErrorReport>prompt</ErrorReport>
<WarningLevel>4</WarningLevel>
</PropertyGroup>
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|AnyCPU' ">
<Optimize>true</Optimize>
<OutputPath>bin\Release</OutputPath>
<ErrorReport>prompt</ErrorReport>
<WarningLevel>4</WarningLevel>
</PropertyGroup>
<ItemGroup>
<Compile Include="MyClass.cs" />
<Compile Include="Properties\AssemblyInfo.cs" />
</ItemGroup>
<Import Project="$(MSBuildExtensionsPath32)\Microsoft\Portable\$(TargetFrameworkVersion)\Microsoft.Portable.CSharp.targets" />
</Project>
Hy,
i have a Xamarin Prism application basically created with the PRISM Template Pack.
My modules are separated dlls.
I want to debug the modules code. So i add the source page in my shell applications visual studio window and set breakpoints.
When i run my application and open Debug-Window-Module dialog, i can see that my module status is "symbols loaded in VM".
So everything looks fine to me.
BUT the debugger doesn´t stop on my breakpoints.
Can anyone tell me what i can do to have debugging?
Thanks
Check out the solution submitted by #Breeze Liu - MSFT for this similar post.
It is possible that you need to edit the .csproj file of the shared project to include the following:
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|AnyCPU' ">
<DebugType>Full</DebugType>
</PropertyGroup>
This particular problem is a big one.
In my current configuration Visual Studio 2013 builds my project if it is in Debug configuration, but not if it is in Release configuration.
Somehow when I select Release, 160 errors pup up and when I go through them they are in impossible places. Here is one example.
Visual studios Error is the following:
Error 3 ; expected E:\Users\Robert\Documents\Visual Studio 2013\Projects\GW2.NET\GW2.NET\GW2.NET\V1\MapInformation\DataProvider\ContinentData.cs 96 36 GW2.NET
And here is the code in question:
public static async Task<T> GetContentAsync<T>(string apiMethod, List<KeyValuePair<string, object>> arguments, Categories category)
{
var response = await GetJsonAsync(apiMethod, arguments, category);
return await Task.Factory.StartNew(() => JsonConvert.DeserializeObject<T>(response));
}
You see there isn't any error. If there were one, the Debug configuration wouldn't build either. I already tried to clean the solution and got the latest from TFS, and I deleted and recreated the configurations.
For now I am at my wit's end. How can I fix this?
The project is a C# 4.0 project with the Microsoft async, JSON.NET, and Rest# packages.
If you are really stuck, one thing you could do is open up the .csproj file in a text or XML editor and inspect the actual XML content in there. You're trying to figure out what settings/properties are set differently based on Debug/Release configurations. This might give you some insight into what it is doing different between the two configurations.
OK, if anyone else has the same problem, here is what I did. Thanks to Dylan Smith, I got to the solution.
Open your .csproj file with a text editor of your choice. I used Notepad++, but Visual Studio is also working. At the top there should be elements called PropertyGroup. Those elements define your build configurations. For me there were two:
One for Debug:
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|AnyCPU' ">
<DebugSymbols>true</DebugSymbols>
<DebugType>full</DebugType>
<Optimize>true</Optimize>
<OutputPath>bin\Debug\</OutputPath>
<DefineConstants>DEBUG;TRACE</DefineConstants>
<ErrorReport>prompt</ErrorReport>
<WarningLevel>4</WarningLevel>
<PlatformTarget>x86</PlatformTarget>
<DocumentationFile>bin\Debug\GW2.NET.XML</DocumentationFile>
</PropertyGroup>
And one for Release:
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|AnyCPU' ">
<DebugType>none</DebugType>
<Optimize>true</Optimize>
<OutputPath>bin\Release\</OutputPath>
<DefineConstants>TRACE</DefineConstants>
<ErrorReport>prompt</ErrorReport>
<WarningLevel>4</WarningLevel>
<DocumentationFile>bin\Release\GW2.NET.XML</DocumentationFile>
<LangVersion>4</LangVersion>
<PlatformTarget>x86</PlatformTarget>
</PropertyGroup>
Apart from the obvious differences, with the first two nodes (DebugSymbols and DebugType), the main difference was the LangVersion element. I deleted it and voilà the project builds in release mode too.
So if you have the same problem as me, open the .csproj file and delete this node. This should solve it.
P.S.: What does the LangVersion element mean? If I change it from 4 to, say, 4.0, I get the following error:
Invalid option '4.0' for /langversion; must be ISO-1, ISO-2, 3, 4, 5 or Default
If you are building a WiX setup project using Visual Studio 2010 with your own custom dialog boxes and your project builds in debug mode, but not in release mode, then go to menu Project → Properties → set Tool Settings to Release Mode and check the checkbox Suppress ICE validation.