Why are the Build generated XCRRequiresAttribNotFound values not the same? - xamarin

In the WinPhone project of a VS 2015 v2 cross platform solution with Xamarin.Forms v2.2.0.13, two versions of ExceptionStringTable.resx are generated in the 'System Xaml/en-US' and the 'WindowsBase/en-US' folders with different contents. At the moment a dependent assembly, XCRRequiresAttribNotFound, found in both files, has conflicting values during build, one having an extra 'a' in the string. Since they are Build generated, why are they not the same value?
Comparison of Values

It looks like you have Platform specific assemblies referenced in your PCL. In this case, it seems that you have a reference to WindowsBase.dll somehow within your PCL. (This could be inside something like PresentationCore.dll or similar).
I would recommend that you do the following:
Compare this against a File -> New Forms Project (PCL) - To see what default references are within Forms by default in the PCL.
Replace any old desktop/platform specific code with the Forms APIs instead - https://developer.xamarin.com/api/root/Xamarin.Forms/
Profit!
If you have any further problems, I would recommend using grep on certain strings like WindowsBase to see exactly where this is coming from. In this case it's a reference to PresentationCore.dll

Related

Maui class library can't compile Android (No Android nameapace)

I'm trying to create a Maui class library that has platform dependent sections.
In the class library's platform section for Android I've added code for Android, but when I compile it tells me that it can't find the Android namespace. I've check the Nuget packages against the main program that does compile Android and there the same. I've unloaded both the main project and the class library and check the project code against each other and there almost identical. The only difference that I can find between the main project that does compile Android is that the class library has an extra net6.0 dependency.
I've created a ".NET MAUI Class Library (Preview)" in VS 2022 Preview 3. Indeed, something is wrong - especially with Intellisense. I did not find a way to suppress certain Intellisense errors, but I did succeed in getting it to build.
NOTE: I confirmed that most of the issues do not interfere with Building the project. Indeed, its possible that the problem is ONLY with Intellisense; I didn't rigorously determine whether Build always worked.
1) OPTIONAL: In .csproj, REMOVE .net6.0; from start of <TargetFrameworks>. BUT DON'T remove, if you are making a library that doesn't contain platform-specific code.
EXPLANATION: This only affects Intellisense; can Build without doing this.
Normally this is wanted in a .net6 class library, but until VS Intellisense correctly handles Maui Class Libraries, with their platform-specific code, this tends to cause extra Intellisense complaints. If you do (4) for all platform-specific files, you can probably leave .net6.0; in, without extra Intellisense errors.
2) Above any source file, is a dropdown that says YourLibName (net6.0-xxx). When working on Android code, pick YourLibName (net6.0-android).
EXPLANATION: This only affects Intellisense; can Build without doing this.
3) In your code, use global::Android instead of Android.
EXPLANATION: Intellisense seems to be confused about the context it is in. global:: ensures that it is looking for a "top-level" namespace.
4) In a class library, Intellisense isn't recognizing platform folders - wrap all code in appropriate #if ANDROID, #if IOS, etc.
EXPLANATION: This only affects Intellisense; can Build without doing this.
This removes errors for a class that is defined differently in multiple platforms; e.g class PlatformClass1.
5) using Android;, using Android.App, etc - do work (in platform-specific folder) when "Build" - even if Intellisense complains.
I had the same problem -- I was determined not to believe #ToolmakerSteve's response but I'm afraid he's correct. Especially #4 of his post about wrapping all platform specific content with
#if ANDROID
#endif
Also add it to your interfaces that reference platform specific namespaces.
Here's a link to a Microsoft page regarding this:
invoke platform specific code

Visual Studio Not Finding 'vulkan-1.lib'

I read this tutorial to try to set up Vulkan in Visual Studio. I got to the very end, compiled, and got this:
A few more screenshots:
I'm using version 1.1.114.0 while the tutorial is using 1.1.77.0, which may be at the root of the issue. However, I have not been able to find another tutorial showing how to set Vulkan up like this. How do I get Vulkan to work in Visual Studio?
I believe you must have missed a step in the tutorial. Specifically, look for the text
Next, open the editor for library directories under Linker -> General
in the linked tutorial page.
In the linker Input tab, either use a complete path to the Vulkan library (for example C:\VulkanSDK\1.1.101.0\Lib\vulkan-1.lib) or in the General tab, add the location of the library (for example C:\VulkanSDK\1.1.101.0\Lib to the Additional Library Directories entry).
If you can express the values in terms of an environment variable, then you'd want to use either VULKAN_SDK or VK_SDK_PATH, which in the above examples would resolve to C:\VulkanSDK\1.1.101.0. That way when you update your Vulkan SDK you don't need to update your project files, and they'll work on other machines that might have different versions installed.
In the long run I'd recommend switching to CMake for project generation, rather than maintaining Visual Studio project files directly. With CMake, adding a Vulkan dependency to your application is as easy as doing this:
find_package(Vulkan REQUIRED)
target_link_libraries(MyApp Vulkan::Vulkan)
You can find existing CMake-based Vulkan examples here or here.

Extracting common code from Xamarin Android project

I've been writing a Xamarin Android app and am now in a position where I have a load of generic business logic (including SQLite.Net stuff). I would like to move this to a separate project, in case I decide to have a go at a Xamarin iOS project. Can this just be a vanilla class library project or is there more to it?
This business logic code contains some strings that will need localizing. I guess the only option will be to store them in a resx resource file in the new project?
For the project itself you can use a PCL, this is in fact my favorite option of sharing code between projects in a Xamarin solution or you can go with Shared Projects which I don't like it very much but many people use it and it works. Here's the link I always use as reference when asked which one to use so you can decide yourself based on the pros and cons of each one.
About the localization you can definitely use a resx resource file but you will need to implement your own localization service to read from the files.

MSBuild/VS2010: How to reference "RuntimeLibrary" compiler setting in a VS2010 "Property Sheet"

I am writing a Visual Studio 2010 property sheet to integrate a complex 3rd party C++ library.
To determine what pieces of the library I need to link to my projects (as well as configuring various defines, includes, directories, etc.), my property sheet needs to determine the project's currently configured C runtime library (i.e. "MultiThreaded", "MultiThreadedDebug", "MultiThreadedDLL", or "MultiThreadedDebugDLL").
However, as a substantially similar question here on stackoverflow pointed out, this MSBuild conditional does not work:
Condition = " '$(RuntimeLibrary)' == 'MultiThreadedDLL' "
Another option was provided, but it was for a subsequent build task. I need this value before ever getting to the build.
I've also scoured Google and Microsoft's MSDN website looking for a way to get this value and have come up empty. Any ideas?
Since there was no way via MSBuild's XML to directly get the configured runtime library, I regex'ed the project file. Here is the XML PropertyGroup snippet to do this:
<PropertyGroup Label="UserMacros">
<RuntimeLibraryRegex>
<![CDATA[<ItemDefinitionGroup Condition=".*']]>$(Configuration)\|$(Platform)<![CDATA['">(?:.*\n)*?.*<RuntimeLibrary>(.*)</RuntimeLibrary>(?:.*\n)*?.*</ItemDefinitionGroup>]]>
</RuntimeLibraryRegex>
<RuntimeLibrary>
$([System.Text.RegularExpressions.Regex]::Match($([System.IO.File]::ReadAllText($(MSBuildProjectFullPath))), $(RuntimeLibraryRegex)).Result('$1'))
</RuntimeLibrary>
</PropertyGroup>
Now the Condition statement in the question will work as-is.
Also, please note that this MSBuild property group XML does not take into account runtime library default (e.g. if the project doesn't have the runtime library set) but can be made to easily.

Whats the difference between <RequiredTargetFramework> and <targetframeworkversion>?

We upgraded our .net 3.5 projects (c#) to .net 4.0. When you look at the project file there are two tags that I'm trying to make sense out of:
<RequiredTargetFramework>3.5</RequiredTargetFramework>
<TargetFrameworkVersion>4.0</TargetFrameworkVersion>
Why are there two seemingly similar tags with different values?
The <RequiredTargetFramework> element was already present in your 3.5 project. It's associated with the assembly <Reference> and only present on assemblies that are not available in .NET 2.0
I don't buy much stock in the single mention of it in MSDN, I don't see how batch building has anything to do assembly references. Nor is it used in any of the 3.5 MSBuild .target files. I think the IDE simply uses it to put the warning icon next to the reference in the References node when you change the Target Framework to a version less than what's needed to support the assembly.
There are other elements like this in a project file that don't affect MSBuild but have an effect in the IDE. Like <SubType> and <DependentUpon> in the <Compile> element.
Have you found this one link? link text. TargetFrameworkversion is easy, that's the one you can change in the project properties to say which framework to build against. The article says that RequiredTargetFramework is used to batch items (but it's still not clear on it' real purpose other than it's not used a lot)
batches the Reference items by their RequiredTargetFramework metadata. The output of the target looks like this:
Reference: 3.5;3.5
Reference: 4.0
Target batching is seldom used in real builds. Task batching is more common. For more information, see MSBuild Batching.

Resources