I am new to Windows 8 App Store development and have bumped into something strange.
If I create a normal .net library (signed library) and attempt to add it to my Windows Store application, Visual Studio 2012 moans that I can't add this project. Both projects are in the same solution.
This project contains a reference to the System.Net assembly, as I use some of the types from there. I know that System.Net is not a fully supported namespace. TcpClient, NetworkStream, etc have all been removed. I also know that StreamSocket, DataReader and DataWriter in the Windows.Networking namespace is the alternative.
Before I loose you, let me get to the point. Instead of adding the compiled assembly from this project as a project reference to the Windows Store application, I browse for the compiled assembly on my hard drive and reference the assembly directly.
To my surprise, this worked! This leads me to the following questions:
Why? That doesn't make sense to me. Someone please explain.
Also, if I use this library, will the Windows Store reject my application? Answering the second question myself... Answer is YES! Windows Certification App, no longer recognises this as a Windows Store App if the mentioned library is referenced.
There are a couple ways to add an assembly reference to a project:
Add assembly reference to a project in same solution.
Browse for an assembly somewhere on your hard drive.
In Visual Studio 2012, if you add a non compliant WinRT assembly reference to a WinRT project, Visual Studio 2012 won't allow it.
However, if you add the same assembly to the WinRT project by browsing on your hard drive, the assembly is referenced successfully. This only works if the referenced assembly is signed with a strong key. I'm not sure if this is a flaw in the product or intentional.
Microsoft makes up for this flaw (if it infact is one) later on when passing your Windows Store App through certification. Certification fails because it recognises that an assembly has been referenced in the project which is not appropriate for a Windows App Store product.
So in summary, you can NOT reference WinRT assemblies in your WinRT projects. The drawback with doing this is that your app will fail Windows App Store validation. The advantage with this is if you are not developing a Windows App Store product, you can re-use work you've already done.
Related
I have a WPF application that gets deployed using ClickOnce. When the user is trying to setup the app on their PC (which is on Windows 10), they get this error:
The application requires that assembly Microsoft.Windows.Simulator.Common version 15.0.0.0 be installed in the Global Assembly Cache (GAC) first.
I've tried looking for that dll everywhere, but have not been able to. Any idea where can I find it? Or what can be the fix for this?
This namespace is in the Microsoft.Windows.Simulator.Client.dll. You can use GIT to pull Microsoft.Windows.Simulator.Client. In the package manager make sure each project that utilizes it is checked. It sound like it needs to be added to the setup project.
I developed WindowsForm application using C# with Visual Studio 2010, and I have external DLL (written using VC++). When I deployed it to Windows 7, everything works fine. However, on Windows 8.1, it installed fine and run fine, until the program needed to access the library function inside the DLL. It complained that it couldn't find the DLL (even though the file is in the same location as the executable).
This happened in Windows 8.1 only (perhaps with Windows 8 as well).
Did I link the DLL incorrectly perhaps?
Assuming that your DLL is a windows native DLL, one of two things is happening:
Windows is failing to locate the DLL
The DLL has other dependencies that are not available on the machine
To check, try changing the PATH environment variable to include the folder that your DLL is in. If the program runs then it's a problem with locating the DLL.
If that doesn't work then you'll need to do some more in-depth investigation to find out what is actually happening.
There's a guide here that shows you how to determine what is happening with your program using Process Monitor to find out what is actually failing to load. This might not be your C++ DLL, it could be one of the many dependencies for it.
The answer is the comment from Harry Johnston above:
Most likely cause: the Visual Studio 2010 Microsoft C runtime isn't installed on the Windows 8.1 machine. Or perhaps the C++ class library. Nothing to do with the OS version, except perhaps indirectly. You can diagnose this sort of problem using Process Monitor, look for file not found errors.
I'm creating a Windows 8 Store App. The front-end (main project) of this app is in HTML5/Javascript. And I'm following this guide by Tim Heuer to create a C# WinRT component that wraps SQLite calls and behave as a controller. The front-end calls this component via Javascript, to update data, and get presentation content.
So there are 2 projects in my solution, 'main' in javascript, and 'db' in C#. I've managed to get SQLite working according to the guide. The reason I have this structure is that I'm trying to port an app from iOS to Win8. The 'controller' part is an isolated component from the get-go, and it's already ported to C#.
However, there is one caveat. Because of this known problem, I have to remove the reference to C++ Runtime v11 from the 'db' project to make it compilable. Though it runs fine in the development machine.
Then I got this test machine (samsung xe700t1a to be exact, Intel i5), I discovered that when 'debugging remote' on this test machine, Visual Studio won't deploy SQLite3. As a result, my SQLite calls fail with error: "Unable to load DLL 'sqlite3': The specified module could not be found. (Exception from HRESULT: 0x8007007E)".
According to the guide I mentioned previously, the point SQLite was made available via WinRT extension, is to make deployment automatic.
I'm wondering why this happens and how to make it correct? I'm also wondering if there's any certification problems for Windows Store for apps in this structure?
I also came across this post and this post suggesting that it's currently not possible to use SQLite in a WinRT component. But it's too late for me to change now, and this project won't be possible without a hybrid structure.
I found the solution. I used the hint from this post, and it's very straightforward.
What I have to do, is to create another project in the solution, with Output Type set to C# Class Library. Move the reference to SQLite for WinRT, and sqlite-net (nuget) wrapper to this new project. After that, I have to manually go through classes in sqlite-net, and change all the 'internal' classes to 'public'.
For the original controller project, I add using myclasslib; so that class definitions are found.
Apparently this workaround will work flawlessly. SQLite3 is deployed, and there's no warning against missing reference.
I am working on a Web Application on a Windows 8 64 bit machine using multiple existing libraries. I want to use two C# DLLs referencing one native DLL. Both C# DLLs are compiled for 64bit usage and tested in test applications.
My web application references both C# DLLs and is supposed to run on IIS 8.
I added the two C# DLLs as references to the project and the native DLL manually to the bin folder of the web app. Whenever I build and run the solution I get the exception shown in the title.
I know that this is a sign for a problem regarding 32 bit and 64 bit code running in one process. Therefore I tried all different build configurations but the result never changed.
I created a console application doing exactly what I'm trying in the web app and it worked flawlessly.
The Web application with the exact same settings however throws the exception, this is what is really confusing to me.
What I tried so far:
Change application pool setting to "enable 32-bit applications"
Build all DLLs with Any CPU, 64Bit or x86 target
Check the corflags of all DLLs
I can provide an export of the project to everybody willing to help me get this configuration running!
I really appreciate every bit of help!
I presume you tried with setting Target Platform (Build option in project properties)?
Also, take a look at this article:
http://www.codeproject.com/Articles/383138/BadImageFormatException-x86-i-x64
I got the same issue on my application. It was fixed after I perform the following:
* Granting permission for the "Anonymous" user in my web site folder.
* Changing the application pool from ".NET v4.5 Classic" to ".NET v4.5".
All I can offer is some help in determining what isn't loading. If it's a dev server it might be worthwhile to install the appropriate sdk to use the Fusion Log Viewer. If that isn't an option you can turn on assembly binding logging from the registry as follows:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Fusion]
"LogFailures"=dword:00000001
"LogPath"="c:\\bindFailureLogs\\"
just be sure to turn it off when you're done, there is a performance penalty using the assembly bind logging. Make sure the folder exists before you enter the registry key and recycle the application pool of the application for the logging to start. This will provide you a detailed list of what dll (or dependency since it's not always readily apparent if it's a dependancy or the dll listed in the error message) didn't load and where it tried to load it from.
Your partitioning of the applications fixing the problem suggests that there are multiple dependencies on the assembly targeting different versions and since only a single version of an assembly can be loaded into an app domain some dependency isn't being satisfied. For managed assemblies you could use an assembly binding redirect, but I don't know what the unmanaged equivalent of that would be if it even exists.
It's not all together clear to me, so I am hoping someone here knows the answer. I am using the C# Json.Net and the C# HtmlAgilityPack both built from sources for "Any CPU". I've noticed that both of these include using directives that reference assemblies that don't seem to be available in Metro yet they both build fine.
If I reference them, does this mean my app will thunk to unmanaged code?
What exactly causes thunking to unmanged code?
Why are DLLs allowed to reference assemblies that are not available to WinRT and my app is not?
Will this fail the windows store approval process?
What are the general rules for DLLs I include with my app that I need to worry about?
Thanks in advance!
When developing apps that target WinRT, the app should only use the API's available in Windows 8 WinRT. The API's are defined in WinMD files. If the app used the desktop API's, then it will be rejected during the Windows store approval process.
Imagine this scenaio. You developed a WinRT app that uses .NET DLL's from desktop mode (client profile). The app is deployed in Windows store and user downloads it on ARM tablet. The application will crash as it does not have the desktop (client) .NET DLL's on the ARM devices.
so this brings us to the question on what .NET classes we can use while developing apps for WinRT. The article http://kishore1021.wordpress.com/2012/08/06/what-is-portable-class-library-project-in-visual-studio-2012-net-4-5/ lists the .NET classes available for WinRT application development.
Change all open source projects dependencies to target WinRT. See if some methods / classes in WinRT are missing so the code does not compile. Try to find the alternative methods/classes.
Such as List.FindAll(), change to Linq Where()