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.

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.

Strong name required for assemblies referenced from unsigned project?

I'm working on a WCF service. The WCF service interface and implementation are in separate projects. There's also a Windows service project to host the WCF service.
One of the things the WCF service implementation needs to do is call out to several external (SOAP) web services. The way we typically structure this is we create a separate class library project for the SOAP service(s); we'll create a Web reference and a factory/helper method in the class library.
The above detail may or may not be pertinent to the real problem. Which is that I get an error when building the WCF service implementation project (where X is one of the SOAP service wrapper assemblies):
referenced assembly 'X' does not have a strong name
But the WCF service implementation project isn't set to be signed (nor is the interface project). And at this point the only two things referencing it are the Windows service project and a unit test project -- and neither of those is signed either.
The WCF implementation also references other (pre-existing) web service wrapper projects, but it's only complaining about these two. I've pulled up an existing and a new project file in a text editor side by side... And I can's see any significant differences.
I've also checked whether any of the projects is importing a setting that requires it to be signed, as described in Stack Overflow question Remove signing from an assembly. That doesn't appear to be the case.
I was attempting to use AutoMapper -- 1.1 since we're still on .NET 3.5 -- in my WCF implementation. That is a signed assembly, so I can see where it might have a problem reflecting on my code and the SOAP service wrappers. But it seems to me that would be a run-time problem, not build time. But because I suspected it might be at least a contributing factor, I removed AutoMapper and the dependent code but I still get the same error.
I have researched the issue, most of the search results consist of instructions on how to sign (possibly third-party) assemblies.
I've tried removing and re-adding the references, restarted Visual Studio and my PC.
Visual Studio 2010 / .NET 3.5 on Windows 7 64-bit.
I'm sure I'm missing something fairly obvious ... I just can't figure out what.

Well ... this is embarrassing.
As I suspected, it was something simple. The service interface and implementation were in fact set to be signed; I was incorrect about that. However, this was done not in the project settings/file, but in the AssemblyInfo.cs file, via the directive
[assembly: AssemblyKeyFile("keyfile.snk")].
I was not familiar with this method of signing. I gather it's been deprecated since VS2005 -- partially because it's more straightforward to manage signing via the project properties, partially because putting this information into the AssemblyInfo is considered a security risk.
And I had in fact looked at at least one of the AssemblyInfo files ... but apparently I didn't scroll down far enough. (I said it was embarrassing.)
Hopefully someone else can benefit from this.

You can not reference an unsigned assembly from a signed assembly, the project which fails to build should be the one that has a strong name key tied to it.
It is possible that you have a signed version of one of your references in the Global Assembly Cache that MSBuild is picking up instead of the reference you selected.

Error loading assembly when retrieving from AppFabric cache

I ran into a weird issue today while debugging one of my projects. I use VS2010 / windows 7 home premium.
I have a project that uses Windows Server AppFabric Cache. I have configured everything, and have created two different C# projects (2 solutions) to test the AppFabric configuration. The project names are "AppFabricServer" and "AppFabricClient". This is just for testing and the naming convention doesn't mean anything specific. I use "AppFabricServer" to Add objects to AppFabric Cache and "AppFabricClient" project to retrieve.
Now, the problem is after running the "AppFabricServer" and then I try to run "AppFabricClient" after closing the "AppFabricServer", I get an error "System.IO.FileNotFoundException: Could not load file or assembly 'AppFabricServer". I don't understand in which way "AppFabricServer" project is related to "AppFabricClient" project.
The same thing happens vice-verse also - this means, after restarting the computer and if I run "AppFabricClient" project first (it also has a Cache writing module), I am not able to run "AppFabricServer" project (it has a Cache reading module as well). I get the same error -"System.IO.FileNotFoundException: Could not load file or assembly 'AppFabricClient".
The exception is thrown at the line where I try to retrieve data from the Cache - when I call the Get method of DataCache.
Can someone please help?

AppFabric utilizes the NetDataContractSerializer to serialize objects. This serializer encodes CLR type information. So, even if the shape of your objects is the same, it actually requires them to be the same types in the same assembly.
Therefore, take the object you are serializing out of the AppFabricServer assembly and put it in a third assembly that is referenced from both the AppFabricServer and AppFabricClient programs. That way, the CLR type information will be the same in both.

C# "Method not found" exception on runtime without usage of reflection

I have a problem with getting above exception. I have a relatively simple structure separate in two dll.
First one contains a IEntityService, IEntity, with basic implementation. Second one contains the actual implementations as well as interfaces. so there is a IMachine service which implements IEntityService and MachineService which implements both IEntityService and EntityService. Similar situation happen for a Result collection( entity plus service). Additionally the service(Machine and result) are partial classes/interfaces where one of the class is auto generated.
Now in one of the ResultMachine I am trying to get a machine and in a case it do not exists I am creating it and saving. However when I am trying to save I got the "Method not found" when trying to access a saving method from a EntityService class. However if I wrap EntityService.Save method in a MachineService it is working without any exception.
Edited:
The code is not required. THe resolution was to re-link the reference. What was misleading for me that my dll is not in GAC, it is linked with VS. What is more it is not strongly signed, the only difference is version number.

We have got this error a few times, you can recreate the problem as follows:
Created project with 2 dll's (say a program dll and a test dll)
deploy program dll to GAC
Add new method
Create test to test the new method
build solution
run test (not in debug mode)
You will now get the method missing exception. The reason is that it is using the old version of the dll that is in GAC and does not have the method.
Some times it uses a cached version of the old dll, IISreset can help.
In your case check for any old versions of the dll.

My first instinct would be to check to make sure the assemblies contained the classes with the missing method. I suppose its possible that the assembly didn't get updated immediately?

When referencing the "same" type from different assemblies, make sure you are loading everything via the same path. Otherwise, identical types can actually be treated as if they are different.
See this article for more: Fusion Loader Contexts - Unable to cast object of type 'Whatever' to type 'Whatever'

This happened to me when I went in and tweaked my build settings to output to /bin/Debug rather than to just /bin in a case when I was also using IIS to host the site from the dev folder.
You need to have the binaries in the same folder as the service, in my case, and the tweak left old versions in the bin folder and put subsequent builds into the /bin/Debug folder (and /bin/Release).
Either keep the settings as is and have a post build action to copy the bits up one level, have different IIS applications for debug/release, or deploy to another folder altogether. The latter is probably most "correct" but for my purposes I just realized after much wheel-spinning, that I had different versions in the service's folder. HTH.

In my case I just deployed on a machine with .NET 3.0 (Windows XP) while the compile target has been .NET 3.5.
This error message is really not helpful.
Problem has been usage of DataContract from System.Runtime.Serialisation.