Usually you don’t need to manually edit .csproj files for your apps and most developers don’t even know what’s going on inside this file. However, sometimes you might run into issues related to this file where Visual/Xamarin Studio can’t help you.
At my current client our solution consists of more than 10 projects:
The categories marked with
(!) were causing build errors. We had to restructure our references and suddenly we couldn’t build some of them anymore.
Error CS0012: The type 'System.Object' is defined in an assembly that is not referenced. You must add a reference to assembly 'System.Runtime, Version=188.8.131.52
Error CS0012: The type 'System.ValueType' is defined in an assembly that is not referenced. You must add a reference to assembly 'System.Runtime, Version=184.108.40.206
… and a few more for
So suddenly C# doesn’t know about
object or enums anymore? If you open the dialog to add references in Xamarin or Visual Studio, there isn’t any option to add references to
It took us a few hours and some research but then we found a pointer in the right direction: the ones causing issues didn’t have references to any other projects in our solution. You’d think those are the ones which are the least likely to cause any issues, right?
The same code worked fine in PCL projects and you can add a reference to
System.Runtime in PCL projects. Whenever we added a reference in the errored projects to a PCL containing the missing reference, the errors were gone. However, this wasn’t a viable option for us.
At the bottom of your .csproj file, you’ll find a couple of lines with all the references from your project looking like
<Reference Include="...." />.
Just add the missing references exactly like the compiler suggests. Eventually we had to add the following references (which were all missing in the Xamarin/Visual Studio dialogs):
<Reference Include="System.Collections" /> <Reference Include="System.IO" /> <Reference Include="System.Runtime" /> <Reference Include="System.Threading" /> <Reference Include="System.Threading.Tasks" />
Dan Rigby wrote a great summary of all the supported PCL profiles in Xamarin. We migrated to PCL profile 44 as we wanted to use a few classes in
After the migration the compiler was warning us that we’re missing out of the fun stuff included in the
Microsoft.Bcl.Build NuGet package.
All projects referencing MyProject.csproj must install nuget package Microsoft.Bcl.Build
So I added it to the projects that showed that warning. But the warning was still there.
Another manual .csproj file edit:
<Import Project="..\..\..\packages\Microsoft.Bcl.Build.1.0.21\build\Microsoft.Bcl.Build.targets" Condition="Exists('..\..\..\packages\Microsoft.Bcl.Build.1.0.21\build\Microsoft.Bcl.Build.targets')" />
Every PCL we migrated to profile 44 contained the line above at the end and the warnings were gone after removing this line.
So would I recommend you to just randomly delete some code? Well no, sir. BCL stands for Base Class Libraries and this NuGet package is meant for older kinds of projects which don’t include all the plumbing required for compilation if they included newer packages like
Microsoft.Net.Http. There are cases where you actually need this NuGet or where you get an error instead of a warning about it. But then you simply wouldn’t be able to compile your code without this magical NuGet.
Before my current project, I had never used custom build targets and tasks. It was my colleague Stefan who showed me how you can use C# to develop custom targets and make your life easier when repeatedly doing a few common tasks before/after your build. We use it to copy or edit a few files, but you could easily extend it to uploading your app to HockeyApp or sending the related DSYM file Xamarin.Insights… As always, the possibilities are endless.