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.
Related
I know there are some posts about Type.GetType() reutrning null, but my problem is, that I have .dll module and use it in desktop version written in c#. This module load configuration from xml, deserialize it and return me filled object. On desktop version it's working right.
Now want to add this into our API running on .NET Core. So I use the same .dll file and use the same method load as on desktop.
In XML we also store Assembly Qualified Name (namespace.class, assembly, version, culture, publickeyToken). On desktop version we create configuration for example in version 1.2.3.4, than make some changes on this .dll, change version to 1.2.3.5 and we are still able to load configuration. But if try to do the same in API, I'm not able to do that, only if in XML is the same version as currently assembly version. Cannot load config with lower version.
I found problem on this row, where typeArgumentName is Assembly Qualified Name.
Type.GetType(typeArgumentName)
If I debug this code with desktop app, it works fine. If debug it with API and change typeArgumenName version to current .dll version, it works. If don't change it, it returns null.
My question is, why it's working on desktop version and return me right type and why it returns me null when use it with API.
This could be happen due to using incompatible C# libraries. I mean if you will use libraries of desktop application into your web API project then it can happen because sometime web version doesn't recognize desktop dlls.
Semi-important Background
I am attempting to change a UWP project to a Windows desktop application so that I can make use of the full .NET Framework 4.5.2. My solution also contains a second project--a Windows Runtime Component--which operates the background tasks. These background tasks write to the ApplicationData so that the primary project with the GUI can use the information. I've made the primary project a Windows application rather than a UWP, but one issue remains:
The Issue
Any reference to ApplicationData.Current.LocalSettings.Values such as
ApplicationData.Current.LocalSettings.Values.Keys.Contains(myDataIndex)
results in the following error:
Error CS0012 The type 'IPropertySet' 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'. ProjectName C:\Users\MyUserName\Documents\Visual Studio 2015\Projects\ProjectName\ProjectName\MainWindow.xaml.cs
So, for some reason, VS is confused on what IPropertySet is.
I've Tried...
Unfortunately, there's nothing starting with Windows.Foundation in the list of namespaces under Assemblies->Framework in the Reference Manager.
Ok, so it's probably already in there somewhere, right...? I'll just try using the required namespace. However, my project cannot find this Windows.Foundation.FoundationContract because my project does not allow
using Windows.Foundation.FoundationContract
though it does find Windows.Foundation.Diagnostics and Windows.Foundation.Metadata.
When I tried this in the original UWP version of the project, it was able to find Metadata, Diagnostics, and Windows.Foundation.Collections. (Curiously enough, the IPropertySet interface my Windows app can't find is actually located in Windows.Foundation.Collections).
This leads me to think that Windows.Foundation.Collections is not available in the .NET Framework used by the Windows app, and only in the UWP .NET Core...? But if that's the case, why does VS still know about ApplicationData.Current.LocalSettings.Values if it couldn't be used? It seems as if I'm missing something else here.
Update
It looks like I just needed to import
C:\Program Files (x86)\Windows Kits\10\UnionMetadata\Windows.winmd
per this answer to fix the reference issues.
(Strangely, I also had to remove a reference to another Windows.winmd file that was at another path. I think that was somehow a result of my attempts to import other things.)
Real Question
Ok, I made it work, but it seems like I'm cheating by importing UWP library stuff. But surely there's a better way?
TL;DR
How am I supposed to use ApplicationData for cross-thread data-sharing in a WPF desktop application without other imports? (And how is it different than a UWP application?
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.
Scenario: Integrating external web application with secure information. Web site calls BizTalk WCF service with one (or more) fields that have been encrypted with web site's encryption class. Inside the publish map I need to convert the web encryption to BizTalk environment encryption (yes, the differences are necessary). This used to be done in the SOAP asmx web service data types code but now needs to be done either in the map or pipeline. Map seemed easiest to implement with scripting functoid reference to external assembly where I call decryptor for the one and re-encrypt with the other pretty much exactly like I did in old web service.
Problem: External assembly is relatively simple in that it consists of one class with default constructor no arguments, with one public method the takes a string and returns a string. Input is web encrypted valve, output is my encryption value. I reference 3 custom libraries for this encryption swap inside the method. None of the referenced assemblies are being called from the scripting functoid. All are added as references in map project. All are strong-named. All are GAC'd.
Yet, when I test the map it gives the following error:
Function 'ScriptNS0:Myfunction()' has failed. Exception has been thrown by the target of an invocation. Could not load file or assembly 'OurCompany.Project.WebEncryption, Version=1.0.0.0, Culture=neutral, PublicKeyToken=123654789abcd' or one of its dependencies. The system cannot find the file specified.
I double checked versions etc in the GAC_MSIL folder and everything matches. What gives?
ARRRGGGG! Curse you Visual Studio! VS was not picking up the changes to the GAC and additionally I don't believe it liked my original dotted namespace/assembly name. I simplified to MapScripting for NS/Asm and restarted VS and it worked. UGH!
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.