I have a Xamarin.Android project that hangs when attempting to build the solution in Release configuration. I've narrowed it down to an issue with the linker - if the linker is switched off, it all builds fine.
I've done the build with higher verbosity and even using msbuild from the command line (which suggests it's not an IDE problem), the result is the same. The build output just up to the point where it hangs reads:
Target _LinkAssembliesShrink:
Building target "_LinkAssembliesShrink" completely.
Input file "obj/Preview/linksrc/BondiToManly.Android.dll" is newer than output file "obj/Preview/link.flag".
Task "CreateProperty" skipped, due to false condition; ( '$(AndroidLinkTool)' != '' ) was evaluated as ( '' != '' ).
Task "MakeDir" skipped, due to false condition; ( '$(AndroidLinkTool)' != '' ) was evaluated as ( '' != '' ).
Using "LinkAssemblies" task from assembly "/Library/Frameworks/Mono.framework/External/xbuild/Xamarin/Android/Xamarin.Android.Build.Tasks.dll".
Task "LinkAssemblies"
Processing resource linker descriptor: mscorlib.xml
Processing resource linker descriptor: Mono.Android.xml
Processing embedded resource linker descriptor: mscorlib.xml
Duplicate preserve in descriptor mscorlib.xml from Xamarin.Android.Build.Tasks, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null of System.AppDomain (Nothing). Duplicate uses (Fields)
Duplicate preserve in descriptor mscorlib.xml from Xamarin.Android.Build.Tasks, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null of System.AppDomainSetup (Fields). Duplicate uses (Fields)
Type Mono.ValueTuple has no fields to preserve
Type System.Reflection.Assembly has no fields to preserve
Type System.Reflection.Emit.ByRefType has no fields to preserve
Type System.Reflection.Emit.PointerType has no fields to preserve
And it really hangs, like a thread deadlock or something. There's no way to cancel the build, you need to just quit the IDE (similarly, ^C in the terminal does nothing either).
This only seems to affect this one Xamarin project I have (many others with similar configurations build fine). At this stage, I'm really just hoping to find a way to get visibility on what's going wrong.
Any hints would be appreciated.
This is not my solution, but the issue was raised and a workaround shared over at the issues list on the Xamarin Android GitHub project at https://github.com/xamarin/xamarin-android/issues/3852
The fix is to remove explicit support for Nullable reference types (<Nullable>enable</Nullable>) from the project file.
For example, in my project file with three configuration/platform PropertyGroups, remove the lines with <Nullable>enable</Nullable>, like:
## -29,7 +29,6 ##
<WarningLevel>4</WarningLevel>
<NoWarn>VSTHRD200</NoWarn>
<LangVersion>8.0</LangVersion>
- <Nullable>enable</Nullable>
</PropertyGroup>
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|AnyCPU' ">
<DebugType>pdbonly</DebugType>
## -40,7 +39,6 ##
<WarningLevel>4</WarningLevel>
<NoWarn>VSTHRD200</NoWarn>
<LangVersion>8.0</LangVersion>
- <Nullable>enable</Nullable>
</PropertyGroup>
<PropertyGroup Condition="'$(Configuration)|$(Platform)' == 'VLU1|AnyCPU'">
<DebugSymbols>true</DebugSymbols>
## -52,7 +50,6 ##
<ErrorReport>prompt</ErrorReport>
<CodeAnalysisRuleSet>MinimumRecommendedRules.ruleset</CodeAnalysisRuleSet>
<LangVersion>8.0</LangVersion>
- <Nullable>enable</Nullable>
</PropertyGroup>
<ItemGroup>
<Reference Include="Microsoft.CSharp" />
Same problem here.
Using Visual Studio for Mac, the Deploy step hangs on the exact same spot.
But using Jetbrains Rider on the same codebase it all works fine. I can deploy and debug my Android App just fine.
Linker configuration:
Related
Last last week I started having an issue with every solution I've tried to build with Visual Studio. I was using VS 2019 and our organization had just pushed down some windows updates (not sure if that's related) but after the updates I was on VS 2019 version 16.8.4, .Net version 4.8.03752.
Whenever I try to build one of our solutions (I tried 3 different solutions after doing a free pull from the main branch of our repo) I get over 1000 errors which seem to be cascade errors from the OutputPath property not being set which seems to be related to several of the projects being arbitrarily changed from Debug to Release even though the solution is set to Debug | Any CPU.
Furthermore, if I examine the build tab on the project properties (or examine them in configuration manager) NO DEBUG CONFIGURATION IS SHOWN AS AVAILABLE. If I close Visual Studio it prompts to me save changes and if I do a comparison shows that it did indeed change the configuration of several projects form Debug to Release.
I have reproduced this on 2 separate machines, with fresh installs of Visual Studio 2019 (and 2017) and pulling fresh code from the repos. Other developers in my org an build the solutions just fine and their configurations show Debug | Any CPU across the board (i.e. I seem to be the only person in the world having this problem and I'm having it on every machine I've tried and with multiple versions of Visual Studio).
I also see errors saying that projects contains nuget references that are "missing" but if I restore nuget pacakges I get a messages saying they are all installed and there is nothing to restore. I also see the "missing" packages in the packages folder.
We use relative paths for the packages so it can't be the typical literal-path issue some people have. Besides which, my folder structure hasn't changed and we all use the same folder structure in our ord.
I am completely at a loss as to what to try next. My googlefoo has completely failed me in this regard.
I'm desperately hoping someone in the Stack Exchange world can offer a solution.
Thanks,
Greg.
Please check if your project's csproj file has missed these content:
You could directly add these at the bottom of the csproj file:
<PropertyGroup>
<Configuration Condition=" '$(Configuration)' == '' ">Debug</Configuration>
<Platform Condition=" '$(Platform)' == '' ">AnyCPU</Platform>
</PropertyGroup>
<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>
After that, delete bin and obj folder.
Then, run update-package -reinstall under Tools-->Options-->Nuget Package Manager--> Package Manager Console to reinstall all nuget packages.
I have a number of projects in my solution, among which also a F# project. Everything builds fine in Visual Studio, but when I try to build it with MSBuild on my TeamCity server (which does not have VS installed) it throws the following build error:
C:\TeamCity\buildAgent\work\42c74d8b9d19a844\FSharpEngine\MY_FSHARP_PROJECT.fsproj : error MSB4057: The target "Clean" does not exist in the project.
[16:27:58]Done Building Project "C:\TeamCity\buildAgent\work\42c74d8b9d19a844\Folder0\MY_FSHARP_PROJECT.fsproj" (Clean target(s)) -- FAILED.
[16:27:58]Done Building Project "C:\TeamCity\buildAgent\work\42c74d8b9d19a844\Folder1\REFERENCING_FSHARP_PROJECT.csproj" (Clean target(s)) -- FAILED.
[16:27:58]Done Building Project "C:\TeamCity\buildAgent\work\42c74d8b9d19a844\Folder2\UPPER_REFERENCING_FSHARP_PROJECT.csproj" (Rebuild target(s)) -- FAILED.
[16:27:58]Done Building Project "C:\TeamCity\buildAgent\work\42c74d8b9d19a844\Folder4\UPPER_UPPER_REFERENCING_FSHARP_PROJECT.csproj.metaproj" (Rebuild target(s)) -- FAILED.
[16:27:58]Done Building Project "C:\TeamCity\buildAgent\work\42c74d8b9d19a844\MY_SOLUTION.sln" (Rebuild target(s)) -- FAILED.
[16:27:58]Done Building Project "C:\TeamCity\buildAgent\work\42c74d8b9d19a844\MY_SOLUTION.sln.teamcity" (TeamCity_Generated_Build target(s)) -- FAILED.
I have installed MSBuild Tools and F# framework on my TeamCity server, but I still don't know why this error is thrown.
Did someone came across this error and can give me some clues on how to fix it? (I've lost a day already and still no luck).
We had the same problem with AutoFixture.AutoFoq and ZeroToNine.
What we did was to modify the .fsproj files.
First, you have to add
<TargetFSharpCoreVersion>4.3.0.0</TargetFSharpCoreVersion>
to the first <PropertyGroup>.
Second, you replace
<Import Project="$(MSBuildExtensionsPath32)\..\Microsoft SDKs\F#\3.0\Framework\v4.0\Microsoft.FSharp.Targets" Condition=" Exists('$(MSBuildExtensionsPath32)\..\Microsoft SDKs\F#\3.0\Framework\v4.0\Microsoft.FSharp.Targets')" />
with this:
<Choose>
<When Condition="'$(VisualStudioVersion)' == '11.0'">
<PropertyGroup>
<FSharpTargetsPath>$(MSBuildExtensionsPath32)\..\Microsoft SDKs\F#\3.0\Framework\v4.0\Microsoft.FSharp.Targets</FSharpTargetsPath>
</PropertyGroup>
</When>
<Otherwise>
<PropertyGroup>
<FSharpTargetsPath>$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)\FSharp\Microsoft.FSharp.Targets</FSharpTargetsPath>
</PropertyGroup>
</Otherwise>
</Choose>
<Import Project="$(FSharpTargetsPath)" Condition="Exists('$(FSharpTargetsPath)')" />
Finally, replace
<Reference Include="FSharp.Core, Version=4.3.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a">
with
<Reference Include="FSharp.Core, Version=$(TargetFSharpCoreVersion), Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a">
If you want to see this in context, you can review the ZeroToNine commit that does the above.
You can create the target "Clean" in your project:
<Target Name="Clean">
<MSBuild
Targets="Clean"
Projects=".\MySolutionDir\MySol.sln"
Properties="Configuration=$(Configuration)" />
</Target>
Or you can modify the command line to something like this:
MSBuild MyProj.proj /p:Configuration=Release;Targets=Clean
I had a problem today with the same symptoms on my build server. What fixed it for me was starting up VS on the build server and creating a F# project, which installed the F# tooling. It was not installed completely by default.
I've created an F# project using one of the Nancy templates in VS2013.
The code is basically just what the template created.
I can import the created .sln file into Xamarin studio and it all builds and runs without any errors or problems.
When I try to push the project up to Heroku though I get the error:
/tmp/build_b3e2706f-20c8-421e-a1ce-781831880466/NancyFirstProject/NancyFirstProject.fsproj: error : /tmp/build_b3e2706f-20c8-421e-a1ce-781831880466/NancyFirstProject/NancyFirstProject.fsproj: The required attribute "Project" in Import is empty
I've set the buildpack on Heroku as follows:
heroku config:set BUILDPACK_URL=https://github.com/aktowns/mono3-buildpack.git
I've read that a similar error can occur if you are upgrading a project via VS2013.
Is this the same error as I'm getting?
Is there another buildpack I can use that resolves this issue?
I guess I can create the solution in Xamarin but I'd like to stick to vs2013 if possible.
EDIT: **
Just noticed this in the .fsproj file:
<Choose>
<When Condition="'$(VisualStudioVersion)' == '11.0'">
<PropertyGroup>
<FSharpTargetsPath>$(MSBuildExtensionsPath32)\..\Microsoft SDKs\F#\3.0\Framework\v4.0\Microsoft.FSharp.Targets</FSharpTargetsPath>
</PropertyGroup>
</When>
<Otherwise>
<PropertyGroup>
<FSharpTargetsPath>$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)\FSharp\Microsoft.FSharp.Targets</FSharpTargetsPath>
</PropertyGroup>
</Otherwise>
</Choose>
<Import Project="$(FSharpTargetsPath)" Condition="Exists('$(FSharpTargetsPath)')" />
I'm not entirely sure why this does not work, but I had to get rid of the <Choose> tag in the F# project file in order to get F# Formatting project to work on Travis (building using Mono) and the change I had to do looks like this (GitHub diff). Sorry for the lack of clarity - I probably copied this from some other project.
The diff replaces the <Choose> tag with:
<PropertyGroup>
<FSharpTargetsPath>$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)\FSharp\Microsoft.FSharp.Targets</FSharpTargetsPath>
</PropertyGroup>
<PropertyGroup Condition="'$(VisualStudioVersion)' == '11.0' Or $(OS) != 'Windows_NT'">
<FSharpTargetsPath>$(MSBuildExtensionsPath32)\..\Microsoft SDKs\F#\3.0\Framework\v4.0\Microsoft.FSharp.Targets</FSharpTargetsPath>
</PropertyGroup>
This issue can now be resolved by using the buildpack from here and specifying a later version of the .net framework.
I have inherited a solution file that uses a MSBuild script to compile multiple solutions. The majority of projects are configured with analysis and rulesets and I have a few unit-test projects that don't.
Projects with analysis turned on:
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|x86' ">
<DebugSymbols>true</DebugSymbols>
<DebugType>full</DebugType>
<DefineConstants>CODE_ANALYSIS;DEBUG;TRACE</DefineConstants>
<Optimize>false</Optimize>
<OutputPath>bin\Debug</OutputPath>
<PlatformTarget>x86</PlatformTarget>
<CodeAnalysisRuleSet>..\OurRules.ruleset</CodeAnalysisRuleSet>
<RunCodeAnalysis>true</RunCodeAnalysis>
</PropertyGroup>
Projects with analysis turned off:
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|x86' ">
<DebugSymbols>true</DebugSymbols>
<DebugType>full</DebugType>
<DefineConstants>DEBUG;TRACE</DefineConstants>
<Optimize>false</Optimize>
<OutputPath>bin\Debug</OutputPath>
<PlatformTarget>x86</PlatformTarget>
<RunCodeAnalysis>false</RunCodeAnalysis>
</PropertyGroup>
When I run my build script, it looks like some projects are not respecting the project settings:
msbuild.exe BuildScript.proj /p:SolutionRoot=%cd%; /p:Configuration=Debug /p:Platform:x86 /p:RunCodeAnalysis=True
When I check the output folder, I see coverage analysis xml outputs for projects that have the RunCodeAnalysis flag set to false. Can someone help me understand what's going on here?
I figured this out shortly after posting it.
Team Build supports the following values for RunCodeAnalysis: Always, Default, Never.
In contrast, locally MSBuild supports True or False for RunCodeAnalysis.
Why are they different? In looking at the Microsoft.TeamFoundation.Build.targets file, the following appears:
<Target Name="CoreCompileSolution">
<PropertyGroup>
<CodeAnalysisOption Condition=" '$(RunCodeAnalysis)'=='Always'">RunCodeAnalysis=true</CodeAnalysisOption>
<CodeAnalysisOption Condition=" '$(RunCodeAnalysis)'=='Never'">RunCodeAnalysis=false</CodeAnalysisOption>
...
</PropertyGroup>
...
</Target>
These settings are then passed onto the msbuild process when it compiles the solution file.
So in other words:
Always tells MSBuild to compile all projects with RunCodeAnalysis=True
Never tells MSBuild to suppress code analysis (RunCodeAnalysis=False) on all projects.
...and not specifying a value for RunCodeAnalysis means that MSBuild will respect the RunCodeAnalysis setting in the project file. Hence, the default setting.
Simply removing the /p:RunCodeAnalysis from my original question had the correct result. Projects that have analysis turned on will run code analysis. Projects without the setting don't perform any extra work.
More information about this is available here: http://www.bryancook.net/2011/06/build-server-code-analysis-settings.html
Change:
<RunCodeAnalysis>false</RunCodeAnalysis>
To:
<RunCodeAnalysis>Never</RunCodeAnalysis>
... and see if that solves your problem. Valid values for RunCodeAnalysis are either {Default,Always,Never} or {True,False}, depending on how you build.
See: Item 12 of How to: Edit a Build Type for more info.
Also, see this article for inconsistencies in the settings of RunCodeAnalysis, depending on how you build: Inconsistent RunCodeAnalysis values
I'm getting an error in a VS2010 DB project that indicates I have too many charachters in my build path.
How can I change my default build path for all project types?
Something like
c:\build\$(projectname)\......
Thanks!
EDIT:
I've moved my project to the root of the C: drive and I still get the error with my DB project. I get this error when I try to right click the project and select properties
An error occurred trying to load the project properties window. Close the window and try again.
Cannot evaluate the item metadata "%(FullPath)". The item metadata "%(FullPath)" cannot be applied to the path "obj\Debug|Any CPU\TASS.DB.dbschema". Illegal characters in path. C:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.Common.targets
The first thing that jumps out to me here is that your platform and configuration are being fused together to form "Debug|Any CPU" and a string is being made from that--the pipe is the character it's referencing there when it says there are illegal characters. I'm not sure how much your database project really differs with respect to debug/release and for architecture, but you may not even need to include them in the path.
Since you can't open the project property pages, you'll need to edit the msbuild directly by unloading it and selecting "Edit..." from the context menu (sorry if you know this already).
From there, assuming you're realling running up on the windows path length ceiling, you could use some msbuild trickery to maximize your headroom in there. Specifically, doing something similar to what you suggest: use the C:\ drive wherever possible.
To do this, look inside the PropertyGroups with the conditions for your Configuration & Platform configurations, and inside them replace the OutputPath and IntermediateOutputPath properties so that they're as short as possible, for example:
<PropertyGroup Condition="'$(Configuration)|$(Platform)' == 'Debug|AnyCPU'">
<OutputPath>$(SystemDrive)\D\A</OutputPath>
<IntermediateOutputPath>$(SystemDrive)\o\D\A</IntermediateOutputPath>
</PropertyGroup>
This saves some valuable characters in that instead of "Debug" you're using "D", "A" for "AnyCPU" and "o" for "obj".
Probably most importantly you're using C:\o\ for the intermediate build directory instead of C:\whatever-the-whole-path-is-to-your-project-file\obj. As well, this property isn't configurable from the property pages, from what I recall.
Some added flexibility there using SystemDrive instead of a hard-coded C:, not that I would really expect it to be different.
Finally, concerning your property pages load problem, I don't know how the Debug|AnyCPU got in your path (I don't know of any properties that store the concatenated flavor like that), but you should be able to pick it out pretty easily once you open up the file. Hopefully it's similar to load errors in something like the winforms designer where you change one line and suddenly the whole thing works again.
Hope this helps!
I don't think it's possible to set a default build path for all projects, only the standard Debug/Release folders within the project itself. The only suggestion I would have is to simply move the project folder to location with a shorter path.
EDIT: As per the new edit, have a look here:
http://connect.microsoft.com/VisualStudio/feedback/details/594333/database-project-template-files-corrupt
I updated a project from VS 2005 to VS 2010 and got the same error message.
"The item metadata "%(Filename)" cannot be applied to the path "obj\Debug|x86\Debug\DemoCSharp.pdb". Illegal characters in path." The problem is that Visual Studio 2010 fails in converting the csproj file to the new format, but it does not tell us where exactly the error is.
In my VS 2005 csproj file there is the following XML code:
<PropertyGroup>
<Configuration Condition=" '$(Configuration)' == '' ">Debug</Configuration>
<Platform Condition=" '$(Platform)' == '' ">Debug|x86</Platform>
<ProductVersion>8.0.50727</ProductVersion>
<SchemaVersion>2.0</SchemaVersion>
<ProjectGuid>{05F88317-0CA7-4FE5-8520-35422402941A}</ProjectGuid>
<OutputType>Exe</OutputType>
<RootNamespace>DemoCSharp</RootNamespace>
<AssemblyName>DemoCSharp</AssemblyName>
</PropertyGroup>
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|x86' ">
<DebugSymbols>true</DebugSymbols>
<OutputPath>..\output32\</OutputPath>
<DefineConstants>DEBUG;TRACE</DefineConstants>
<DebugType>full</DebugType>
<PlatformTarget>x86</PlatformTarget>
<ErrorReport>prompt</ErrorReport>
</PropertyGroup>
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|x86' ">
<OutputPath>..\output32\</OutputPath>
<DefineConstants>TRACE</DefineConstants>
<Optimize>true</Optimize>
<DebugType>pdbonly</DebugType>
<PlatformTarget>x86</PlatformTarget>
<ErrorReport>prompt</ErrorReport>
</PropertyGroup>
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|x64' ">
<DebugSymbols>true</DebugSymbols>
<OutputPath>..\output64\</OutputPath>
<DefineConstants>DEBUG;TRACE</DefineConstants>
<DebugType>full</DebugType>
<PlatformTarget>x64</PlatformTarget>
<ErrorReport>prompt</ErrorReport>
</PropertyGroup>
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|x64' ">
<OutputPath>..\output64\</OutputPath>
<DefineConstants>TRACE</DefineConstants>
<Optimize>true</Optimize>
<DebugType>pdbonly</DebugType>
<PlatformTarget>x64</PlatformTarget>
<ErrorReport>prompt</ErrorReport>
</PropertyGroup>
Visual Studio does NOT tell us which line produces the problem. But I found it by "try and error".
The cause of the error message is clearly a bug in the Visual Studio conversion wizard because VS 2005 has no problem loading this csproj file while VS 2010 fails to convert it.
So you have to manually edit and fix this file and then load it anew in VS2010.
In my case the line that triggers the bug is the 3. line with <Platform Condition. The bug is that VS tries to take the value ("Debug|x86") of this platform condition XML node and embed it into a path on disk (like "...\obj\Debug|x86\..."). But as pipe characters are illegal in paths, it later complains and aborts the conversion.
So how to solve the problem ?
I simply replaced the third line
<Platform Condition=" '$(Platform)' == '' ">Debug|x86</Platform>
with
<Platform Condition=" '$(Platform)' == '' ">Debug</Platform>
which eliminates the pipe character and the project converted without errors.
NOTE: It is also possible to completely delete this line.
ATTENTION:
It is possible that in YOUR case the same error messages needs another fix than in my case. Please study the csproj file and look for the pipe characters, then find out with try and error how to modify it. This error can even appear in other conditions than converting a project.
But what they all have in common is that this is a Visual Studio bug (or in case of 'littlechris' a software extension bug) that tries to embed a pipe character into the path.
XML node: "Debug|x86" -> path "...\obj\Debug|x86\..."
I received this messeage because the absolute path of one of the files in my project exceeded 260 characters. Once I reduced the path length, I was able to build the project.