my app is developed in C#. We have a WinRT component, which uses the c++ libraries. After adding a reference from C# project to WinRT, everything is fine. Compilation without errors. But if I try to create new object, I get exception FileNotFound. The reason is, WinRT component doesn't have dependency dlls. So I tried to add them in project, set Content = true, but it is not working. The libraries are not included in the package, so are not deployed to mobile emulator. When I try to run the app on desktop, it's not working too. I have to copy the dlls manually to Appx folder.
Please let me know, if you have some advice for me.
Thank you
Related
I want to create a g application with C# and Windows Forms. For this I have downloaded and installed the latest nuget from the official website (https://download.linphone.org/releases/windows/sdk/). But now when I want to make a call, the programme crashes with the error:
DllNotFoundException:linphone.dll
I have now tried various things: modify LinphoneWrapper.cs, integrating dll file into the project, dll file in bin folder, ... but had no success.
I tried the same thing with C# UWP and it worked without any problems. But UWP does not look like the right way to me.
I am still inexperienced: Is it even possible with this nuget and Windows Forms, or do I have to download and build (cmake) the linphone-sdk first?
Thanks for help.
Are you building for x64? linphone doesn't support targeting x86 (look here)
I have previously developed a Windows Universal App.
I would like to migrate all the non-platform specific code to place in a portable class library project for further development.How to achieve this?
In the Windows Universal App there are some backend C# code controlling UI contents and manipulate the data as well. I may not able to seperate the non-platform specific code nicely. Can I still migrate to PCL project in this case?
I searched on the portable class library documentation as the link below:
https://msdn.microsoft.com/library/gg597391.aspx
The description looks confusing. Does it mean that I just include my previous app package in the PCL project and then everything works?
How to Migrate
Unless you changed your question title to "how can I move platform independent portion of my code to PCL", I believe no others can easily understand your meaning.
I assume that you already have a Windows Universal app project in Visual Studio. Then to move code to PCL,
Simply create an empty PCL project (choose a proper profile), and add it as a reference to your original Windows Universal app project.
Cut (not copy) and paste some source files from your app project to this PCL project.
Compile the solution and fix issues.
If you don't know what is a PCL profile, read MSDN related materials. If you don't know which source files should go to PCL, and which should remain in app project, do experiments or check out other guys' sample project.
About The Confusion You Got
I can only say to understand what you highlighted, you should read carefully what is not highlighted in the same sentence, and the subtitle.
Clearly when you have a PCL project, and a Windows Store/Phone app project that references the PCL, when you generate the deployment package (.appx) in Visual Studio, the final package will include every needed assemblies.
It obviously isn't what you described.
You will need to extract the platform specific code. The docs you quote go in the other direction: the PCL is included in the appx package, not the app package in the PCL.
Depending on how entrenched the platform specific code is you may be able to separate it out via inversion of control: define an interface the PCL can use to call back into the host to acquire platform specific data which the PCL can then manipulate.
For example, if the current code has platform specific code to open a file and get its contents, the PCL could call a funtion in the host which opens a file and returns a stream to the contents.
I am having a lot of problems when trying to integrate Parse with cross-platform Xamarin app. At first, I was able to create Android app using Xamarin and MvvmCross and integrate with Parse service (done by adding Parse component in Xamarin). When it comes time to develop iOS app, I am having problem to refactor out Parse dependency into Core PCL project, since Parse currently doesn't support Xamarin PCL projects. Hence, there is no Parse NuGet package or Xamarin component that can be added to PCL project. I can easily add Parse component to iOS project and Android project respectively, but that will require lots of code duplication across both projects.
I've read that referencing Parse.dll and Parse.NetFx45.dll in Core project enables me to use Parse calls in Core project. I did this and are able to compile everything successfully. However, when I try to initialize Parse in Core project using ParseClient.Initialize("ApplicationID", "DotNetKey");, I get TypeInitializationException during runtime.
Question is, what is the best way to integrate Parse service with Xamarin & MvvmCross cross-platform application? I'd imagine lots of people would have done this, but couldn't find references/examples. Duplicating codes across both iOS and Android project definitely shouldn't be the way to go.
Here are a couple of ideas:
First, if you are currently manually copying Parse code changes from project to project, you could speed up that process by writing a script that you run that would clone certain files to the other project. Or you could maybe write a grunt script that copies files automatically when it detects a change.
Now, here is another approach that stores Parse code in one project but is shared across platforms:
The Problem: I was using a Shared Project instead of a PCL to house my Xamarin.Forms and Parse code. The Parse code was working just fine, but I ran into an issue when trying to use my own custom ContentView in my ContentPage in XAML. I wanted a solution that would allow my custom ContentView to work as well as my Parse code -- both from the same project.
The Solution: I have switched to now housing my Xamarin.Forms and Parse code in a PCL. But there is a small catch. Before I explain the catch, just know that it does work with NO Parse code duplication (except for the one line of Parse initialization code that goes in each platform's specific project).
What's the catch? The catch is that in your portable class library you have to manually swap in and out either the Parse.iOS.dll or Parse.Android.dll depending on what you are compiling for at the time.
Does it increase the file size? No. I tested with my app using a Shared Project (where it uses the platform project's referene to the Parse dll) versus a Portable Class Library (where you have to add a reference to the dll in the platform's project as well as the PCL) and found no increase in the app file size by doing it this way.
Below is the project structure that is currently working for me (with project names renamed for confidentiality). (FYI: I am using Xamarin for Mac.)
MyProject.iOS
- Reference to Parse.iOS.dll
- Reference to the Portable Class Library
MyProject.Android
- Reference to Parse.iOS.dll
- Reference to the Portable Class Library
Portable Class Library
- Parse Code
- Xamarin Forms Code
- Reference to either Parse.iOS.dll or Parse.Android.dll
Important: When swapping out the DLL in the PCL, I found that if I right-click the DLL under the References menu, and then click Delete, it caused issues in my project where the iOS project wouldn't compile anymore because it was still looking for the Parse.Android.dll or vice-versa. I tried cleaning the solution, deleting bin and obj folders from the solution's file system to no avail. I got it to work again by doing this: Right-click References, click Edit References, and then uncheck the one Parse DLL and check the box for the other. However, then after that, I tried the "Delete" method again and didn't have problems compiling. Who knows, maybe that issue will crop up for me again.
Won't this get annoying? Depending on how often you switch between platforms, the manual swapping of DLLs may or may not get annoying. No matter how annoying that is though, it can't be worse than having duplicate code. (Perhaps this swapping process could be automated with a script? I think you'd have to unload the PCL and reload it though if you modify the .csproj with a script. Anyone out there up for the challenge? Or perhaps there is a way to do a conditional reference to the DLL based on the platform it is compiling for. Thoughts anyone?)
I hope this helps. If you like any of these ideas better than what you are currently doing please accept this as the answer and let us know which route you decide to take.
Isn't the best way to to this, to create a Parse Plugin for Mvvmcross? Where you define your interfaces that want to use.
And in each platform specific library you reference the parse dll and call the method. So in you Core project you should be able to call the IParse.methods...
So I got it working fine on both Android and iOS by referencing Parse.Android.dll in all 3 projects (Core, iOS, and Android). Yes it sounds weird, but that's what's working for me. Just go to Parse download page and download Xamarin SDK under Android section. It works wonders too! No code duplications, no mess :)
I am a Visual Studio 2013 Newbie who is trying to figure out how to build a C DLL in Visual Studio and then invoke the functions exported by the C lib from within a C# app. I've got everything building, but I cannot figure out the proper way of getting the DLL included with the app build so that it will actually load properly when using [DLLImport()]. I currently get a System.DllNotFoundException when attempting to invoke a function from the library from within my C# class.
I have setup a VS 2013 solution which contains the following projects:
HelloWorldLib.Shared :
Shared project that contains the .cpp and .h files for the DLL
HelloWorldLib.Windows :
Win 8.1 C++ project that references the shared project and builds the DLL for Win 8.1
MyApp-Win.Windows :
C# project for Win 8.1 that wants to make use of the HelloWorldLib.Windows.dll produced by the HelloWorldLib.windows build
I have been looking over many SO questions and answers. For instance, I think my question is similar to this one, which doesn't appear to have been answered in any useful way:
Interop, Native DLL and Visual Studio build process
Some of the other answers suggested adding a file reference to the DLL, but how would I do that and keep the proper Debug/Release versions? Given that all of these projects are being built within the same solution, and there are build dependencies between them, it feels like there should be a straightforward way to set this up.
BTW, I am using the shared project setups, as my ultimate goal is to figure out how to get this all working with Xamarin to target iOS, Win, Win Phone, Mac and Android. So that we can use a common C/C++ layer for our high performance requirement code, and the reference it from the UI layers on the various platforms.
This is a pretty straight-forward problem, easy to identify if you look where the built files end up. The C++ build system has a different strategy than the managed build system. It by default writes the build output to the solution directory's Debug directory. Your C# project however builds to its bin\Debug directory and requires all dependent DLLs to be present there.
So, by default, your C# program can never find the DLL, it is in the wrong directory and Windows doesn't look there. Nor is MSBuild smart enough to discover this by itself, like it can for managed DLLs, it cannot see that you program depends on the C++ DLL.
Two basic ways to work around this:
Change the C++ project's Output Directory setting
Write a post-build event for your C# project that uses xcopy.exe to copy the DLL.
Unfortunately things aren't that easy, at least not yet. I was going to have a meeting with Microsoft C++ team but that got postponed, similar functionality you are after was one of the things on my wishlist (building managed C++/CLI wrappers for Xamarin.iOS and Android).
Currently, if you can, the easiest option is to wrap C++ code inside a DLL that exposes C interface. Then build it with XCode and Android NDK. If you can't then the next option is to create Objective-C binding project that wraps the C++ code inside Objective C classes for iOS. For Android either create Java wrapper or use SWIG. Both of these options are cumbersome which is why C API should be the first choice you investigate.
I know it's not the answer you were hoping for but reusing C++ code is way more complicated than reusing C# or even C.
I am writing a Windows 8 Store app using Visual Studio 2012. The main app is a XAML/C# app but it also uses a WinRT component written using C++/CX. For the WinRT component, I am using the VS project template called "DLL (Windows Store apps)" from the New Project dialog. Once I have this project, I change it to contain a single namespace with a single ref class. My C# project contains a reference to this C++ project.
However, when I try to run my app, the C# code throws an exception at the point it tries to instantiate/activate the C++ ref class. I have seen several working examples of this even on MSDN samples. I have verified that the WinRT component DLL and the winmd files are correctly copied into the final app package, and also that the app's AppxManifest.xml is properly updated with the correct registration information for the WinRT class. However it still fails.
I don't know what's going wrong. How can I fix this error?
Windows Runtime component binaries are required to have the following two exports:
DllCanUnloadNow
DllGetActivationFactory
When you use the VS project template "DLL (Windows Store apps)", your project doesn't define the requisite macro that causes the compiler to put the above two exports in the binary. Under project settings you will notice that the macro set is _WINDLL. You will need to change this to _WINRT_DLL.
Alternatively, the correct way to create a WinRT component using C++/CX is to use the VS project template called "Windows Runtime Component" under Visual C++ -> Windows Store. Using this will create a project which is already correctly setup with the right project settings etc. for creating proper WinRT binaries.