We Keep Coding

C# VS2017 IStringable Unreferenced Exception using Windows.Data.Json

So I'm going to jump straight in.
I'm using Windows.Data.Json to convert and use some JSON from a web service. I know about Newtonsoft.Json.Net, and some of the others etc. and yes, I am specifically trying to use Windows.Data.Json, for company and dependency reasons.
The application has 3 main parts/components.
A UWP Win 10 app - the main app
An MVC Web Project - web services for the app
A Portable Class Library - for shared classes between both
The problem I have is that when I use JsonObject in either the MVC web project or the PCL, I am getting the error:
The type 'IStringable' is defined in an assembly that is not referenced. You must add a reference to assembly 'Windows.Foundation.FoundationContract, Version=2.0.0.0, Culture=neutral, PublicKeyToken=null, ContentType=WindowsRuntime'.
This error is showing up everywhere I use the JsonObject, however, NOT in the UWP app project.
e.g.
//Convert string to json object
var apiJsonObj = JsonObject.Parse(jsonString);
and
cc.Type = apiJsonObj["TYPE"].ToString();
I've searched online, and cannot find anything useful about Windows.Data.Json, nor the IStringable, other than this:
https://learn.microsoft.com/en-us/uwp/api/windows.foundation.istringable
My project does not have Windows.Foundation.FoundationContract listed in the Add References dialogue, and I cannot find any references to it in the UWP app that I am using, nor any other information that has been of use.
The UWP app and the MVC Web app use literally the same lines of code to interpret the JsonObject. The UWP app works. The MVC Web app gives the above error.
I was wondering if anyone else has been using Windows.Data.Json successfully, and may have come across this issue, and a fix?
The applications must be as small and independent as possible, hence the small number of references, and not being able to use Json.Net etc.

This error is showing up everywhere I use the JsonObject, however, NOT in the UWP app project.
The Windows.Foundation.FoundationContract assembly is platform specific. You could not use it in your portable library. It will throw compiling error, though you can add the reference via pick winmd file where in the below folder.
C:\Program Files (x86)\Windows Kits\10\References\Windows.Foundation.FoundationContract\2.0.0.0\Windows.Foundation.FoundationContract.winmd
Currently,Json.NET has supported portable library, you could use it to parse json. You could chose Json.NET which does not cause complex assembly dependencies.

How to handle new releases of third-party .Net assemblies without recompiling?

I have some projects that rely on external .Net assemblies to operate. These are installed externally from my program so I do not have direct control over what version is being used. Furthermore, updates are expected to be installed as a matter of course.
For example, in one case I am accessing a hardware device that provides a .Net interface to control it. When the user initially installs the device, they install the driver that is included. This driver when I wrote the program may have been 3.0.4.0. The latest version might be 3.1.8.0.
My program fails to load the assembly when this happens complaining that the manifest definition is incorrect. A specific exception message is show below.
Another example is a labeling program. They provide a .Net interface to allow my program to print labels through their system. Installing an updated version of the program is fatal.
Here is the specific exception message:
Could not load file or assembly 'SDK.NET.Interface, Version=17.1.0.0,
Culture=neutral, PublicKeyToken=865eaf3445b2ea56' or one of its
dependencies. The located assembly's manifest definition does not match
the assembly reference.
If I install this version of the application on my computer, then reference the updated version of the assembly and compile, I’m good to go . . . for now.
But, it’s only a matter of time before I will have the issue again.
I’ve tried setting the Specific Version property of the referenced assemblies to False but that didn’t affect the problem.
What is the proper way to address the issue?

You are able to "Plug and Play" as long as method signatures don't change.
If those change, then you'll need to fix your base code.
Look at Microsoft's documentation on Redirecting Assembly Versions:
http://msdn.microsoft.com/en-us/library/7wd6ex19%28VS.71%29.aspx
Another option is If these libraries are somehow controlled by you or your company, you might have some wiggle room with reflection by loading them up by their base type/interface and using common methods... but you'll need to have access to the base types.
This is also a duplicate question:
Upgrade a reference dll in a C# project without recompiling the project
Upgrading dependent DLL without recompiling the whole application

Could not load an assembly despite it being referenced

I'm looking at incorporating the new Google Apps Script Execution API into an existing C# plugin i have already working. I am following the .NET quickstart guide provided as a console application (which i have gotten working without problem).
When porting the code from that into my plugin it will also fail at runtime at the first instance of:
UserCredential credential;
which I slimmed down the code so far to just that line which fails giving:
"Could not load file or assembly 'Google.Apis.Auth, Version=1.9.2.27817, Culture=neutral, PublicKeyToken=4b01fa6e34db77ab' or one of its dependencies. The system cannot find the file specified."
The file is properly referenced (having installed via nuget).
C# is not my normal field and perhaps i'm missing something in the subtlety of it working in a Console App.
What gives?

There was a time when console apps defaulted to using the client profile rather than the full .Net framework. Check the properties of the project on the Application tab and make sure the target framework doesn't end with Client profile. If that doesn't work try using the fusion log viewer, which you'll find conviently located at C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bin, or any number of other places. Run it as an admin and it'll tell you what it can't load (which may or may not be Google.Apis.Auth) and where it looked for the file at.

This has been a little bit of a red herring. Not very well documented is the fact for the app i am building against, Autodesk Navisworks,
plugin dependency libraries have to be duplicated in a separate directory altogether from the plugins directory.
Easily fixed for the build environment, but will need a little more thought for when creating a distributable.

WPF Application Incorporating WinAPI (Win8) components

I have a WPF application which utilizes a handwriting control.
By using an
<InkCanvas></InkCanvas>
In my XAML, I was able to get the user's strokes, and turn them into text using the InkAnalysis class. However, this is strictly 32bit, and my requirements dictate a 64bit build.
Unable to find a 64bit compatible library, I looked into upgrading to .NET 4.5 and utilizing the Windows8 classes which are available to desktop apps (by also adding
<TargetPlatformVersion>8.1</TargetPlatformVersion> to the csproj file so that I could add the 'Windows' namespace references). Luckily, Windows.UI.Input.Inking is.
However, when I add the reference to Windows.UI.Input.Inking, I get a build error which states:
Unknown build error, 'Cannot resolve dependency to Windows Runtime type 'Windows.Foundation.Metadata.PlatformAttribute'. When using the ReflectionOnly APIs, dependent Windows Runtime assemblies must be resolved on demand through the ReflectionOnlyNamespaceResolve event.'
I have looked into the:
Windows.Foundation.Metadata.PlatformAttribute
And it seems to want an enum member, either:
Windows.Foundation.Metadata.Platform.Windows
or
Windows.Foundation.Metadata.Platform.WindowsPhone
This is a desktop application, so I would obviously choose to target Platform.Windows, but cannot figure out how to tell the compiler this.
How can I incorporate this Windows.UI.Input.Inking class into my WPF application? My end goal is simply to convert strokes from the inkcanvas into text, in a 64 bit environment.

I discovered that I was receiving this error due to the reference added to the:
Windows.UI.Input.Inking
library. It seems that the correct way to add reference to Windows 8/8.1 WinAPI components (from a non WinAPI application) is the following:
Add <TargetPlatformVersion>8.1</TargetPlatformVersion> to the csproj file
Add reference to the Windows library (this is the key - adding the specific lib, in this case, Windows.UI.Input.Inking, causes the build error)
Add the more specific (ex: Windows.UI.Input.Inking) reference in the actual file where the API is required
I am working on creating a NuGet package which will edit the csproj file, and add the Windows reference. I'll update this if/when it is completed.

Errors trying to load an assembly in C#

Ok this question is more about understanding what the issues are as I dont think anyone will be able to tell me how to fix the problem.
I am writing a .net 4 application and I have a 3rd party dll ( hasp dongle protection ) that I want to reference.
Visual studio allows me to create the reference fine and use classes contained within the dll within my code.
The first issue occurs when the program is run and the dll is actually loaded. I then get the following error.
System.BadImageFormatException: Could not load file or assembly
'hasp_net_windows.dll' or one of its dependencies. is not a valid
Win32 application
This weblink states how to fix this error. Coud someone expalain what the issue is and why im getting it.
After following this advice I then set the main project build to x86 and I then get another error replacing the other. The new error is:
System.IO.FileLoadException: Mixed mode assembly is built against
version 'v1.1.4322' of the runtime and cannot be loaded in the 4.0
runtime without additional configuration information
This weblink states how to fix the error, but I dont have an app.config in my project and want to avoid having one if at all possible. If someone could explain what the issue is again that would be helpful?
Please let me know if you require anymore information.

The issue is the "bitness" of your application. Once chosen (32 bit or 64 bit) all DLLs within that process need to be the same. This exception tells me that one of your DLLs is the wrong "bitness".
You simply cannot have DLLs with different compilation targets within a given process, a process has "bitness" affinity.
If this is a third party unmanaged DLL then it is very likely 32-bit compiled.
Setting the build output as x86 for the root project (the one that creates the exe) should suffice as this will dictate the process that is created. Any other .NET projects can then simply be Any CPU and will fit in either the 32 or 64 bit runtimes.
Unfortunately for your second issue, the provided link is the way to solve it. There is nothing wrong with having an app.config in a project and you haven't stated why you don't want one.

The answer by Adam Houldsworth notwithstanding, I'd like to add that it is possible to do it without an app.config. However, this requires a tiny bit more work and potentially a proper understanding of COM interop. Whether it's worth the trouble is up to you of course ;).
You can set useLegacyV2RuntimeActivationPolicy programmatically by using the ICLRRuntimeInfo::BindAsLegacyV2Runtime method.
A quick rundown on how to do this is posted in this blogpost. Take note of his warning though, which might make you think twice in using this approach:
This approach works, but I would be very hesitant to use it in public
facing production code, especially for anything other than
initializing your own application. While this should work in a
library, using it has a very nasty side effect: you change the runtime
policy of the executing application in a way that is very hidden and
non-obvious.

I cannot use an app.config file because the assembly is loaded via COM from a native program.
I found the library that supports .net framework 4.0. here. In this scenario, no other solutions had worked for me.