I know, there is an issue with System.AppDomain.CurrentDomain.GetAssemblies() in the Portable Class Libraries. To overcome it, I have decided to extract the list of assemblies in the target application and send it to my PCL as custom objects.
This was easy when using single-platform applications (pure WinForms, pure WP 8 application, etc.). However, I cannot find any suitable replacement for the method in Windows 10 Universal apps (and the documentation for both PCLs and Win 10 Universal Apps is pretty bad, so far). The reason, why PCLs are not able to get a list of assemblies is simply because the library does not know of all the assemblies, until it is built and packed into DLL. However, that cannot be said of the Universal App, since it should run the same system (Windows 10) -> therefore, it should be the same program on both PC and Phone -> therefore, the application should know of all its assemblies already before compiling.
So, does there exist a suitable replacement for this method, or some workaround how to get all the assemblies inside the app?
EDIT: I have found this workaround, which loops through all .dll and .exe files... however, that seems extremely unreliable. Is there a cleaner/better way?
Related
I have an proprietary Android app (created with Android Studio) and I need to add some functionality which requires to use a C# DLL.
The app is connecting wirelessly to a development board that does some sensor measurements. Normally on windows apps the dll is used to do some complex calculations of calibration coefficients for the measuring.
My problem is:
I don't have the the source code of the DLL and most likely I won't be approved to access it.
I've read that you can use xamarin to make android apps and use C# dlls but I can't rewrite the whole app for xamarin just to use the dll (also I've never used xamarin)
So far I had the idea to build a simple http server with C# that gets parameters with a GET request, runs them through the dll and returns the results. However it's not an ideal solution because it requires a separate pc to run the server and the adndroid device to have a network connection to it.
My second idea is to build a separate app with xamarin that uses the dll and make my main app start it just to calculate the coefficients and get the results. Perhaps make the second app not visible in the launcher and somehow distribute the two apps together.
Since I am not experienced with android development and especially xamarin and I don't have a lot of time to waste on this project I want to know if my idea is feasible or if there is a better alternative.
Can you suggest some useful tutorials for xamarin and using dlls with it?
===============================================
Edit
I have managed to get the source code of the dll project which is in C++ (and full of windows only stuff) and now I'm trying to use NDK to compile it and JNI with Android studio to use the native functions. Unfortunately almost every step has it's own quirks and problems and it's far from smooth :/ I wouldn't recommend it to beginners like me!
I know this answer is late, but I'm in a similar situation right now.
This project here helped me setup a native Android Studio build with an embedded C# lib:
https://github.com/royd/KotlinAppWithXamarinDependency
The only issue I'm facing right now, that I can't get the R8 obfuscation/optimization to work without breaking the app.
I have a Windows 8.1 C# project for windows store ready.
I want to make a copy of it for Windows Phone 8.
Is there any good and easy way to do this?
I use Visual Studio Ultimate (2012 and 2013).
There's no simple/automatic way to do it, but the code will be mostly compatible. The UI will probably need to be adjusted significantly.
If you target Windows Phone 8.1 WinRT you will find more of the code will work (Windows Phone 8.0 does not support WinRT, which is what Windows Store 8.1 apps use).
A possibly better way would be to create a new Universal Windows 8.1 WinRT project and copy your existing project code in, placing as much as possible in the shared project (or in class libraries), then create a new UI for the phone version (you can keep most of the actual code behind in the shared project - see my blog post here: http://grogansoft.com/blog/?p=760 - to minimise duplication. Note that this must target WP8.1, not 8.0.
If you absolutely must target WP8.0 then you may have no better option than to just copy in the code and adjust it where necessary. This will be relatively easy for a simple app, but relatively messy for a complex app that happens to use APIs that don't match up.
Well, they are different platforms, so you'll still have to adjust your code for that, but maybe converting your portable code to a portable class library will help you:
http://msdn.microsoft.com/en-us/library/vstudio/gg597391(v=vs.110).aspx
Usually it is recommended to have two projects for both wp7 and wp8 platforms. Wp7 project contains .cs and .xaml files, and WP8 project contains links to that files.
I think that there is no reason to compile non-platform specific business logic code twice, since it can be referenced to WP8 project.
I'm thinking about following solution structure:
Business logic dll compiled for wp7 (not a PCL)
UI comliled for wp8
UI comliled for wp7
Such application can be compiled and I can deploy it to device/emulator.
The question is: will this app pass certification in Windows phone store? Or it is necessary to recompile shared dll?
UPD:
My crazy idea was born after this steps:
Create new WP7 app (WindowsPhoneApplication1)
Create class library targeted to WP7 (WindowsPhoneClassLibrary1) Use it in WindowsPhoneApplication1
Use Upgrade to WP8 menu. WindowsPhoneApplication1 will be updated to WP8, but the referenced project will be still targeted to WP7!
Such app can be deployed to WP8 devices.
Unless you use a Portable Class Library, you'll need to have separate project files, and compile separately for WP7 and WP8.
Thanks to Claus,
I made some research, and it looks like the answer is - you can use such solution.
I didn't find related information in documentation, but here is a proof from one of MSFT tech. evangelists from Netherlands: link to blogpost
The basic idea is to move all our code that can be used from both our existing Windows Phone 7 app as well as the Windows Phone 8 build, which we will add soon, to a Common project in the solution. The bad thing about this approach is that we have to create the Common project as a Windows Phone 7 class library, which will be used in our Windows Phone 8 build. I haven’t really noticed any negative impact of this decision in my existing apps, but note that you will be referencing a Windows Phone 7 library in your Windows Phone 8 build.
So it is a possible, but not the best solution.
Would it be possible to code and compile C#, on a Windows 8 Tablet (WinRT) (the ARM processor edition)?
Basically it comes down to this:
Is there a C# compiler that runs on ARM?
Is there and IDE that can run in WinRT?
If the above is true, I don't see any issue, but I currently can't find if the C# compiler runs on ARM (only a lot of posts about compiling for ARM). I've also looked at SharpDevelop, and found that their source code compiles for "Any CPU", which according to this post: Windows RT and c#, means that it'll run on ARM.
Sharpdevelop however requires .NET 4.0 "Full" runtime, which I couldn't find if WinRT has or not. I'm betting it doesn't, as WinRT is supposed to be a really lightweight edition of Windows.
As a sidenote, I know that Windows tablets will come in two editions, one for ARM and one for classic processors. The classic processors will run a normal Windows 8 edition, which means it can run all the native applications. Compiling C# wouldn't be an issue here - so the question is rather, can I do the same on ARM?
This would be awesome for travelling and trying out new ideas quickly.
Currently: no, and no.
It would certainly be possible to build a Windows Store app that contains an IDE and a C# compiler. However, you would not be able to run any programs built using such an app. Windows Store apps run with reduced privileges in a sandbox. In this sandbox, the CLR will only load system assemblies and assemblies contained in the app package. The app package is immutable and cannot be modified at runtime.
Actually, the .Net framework on the surface includes csc.exe, the Csharp compiler.
I've gotten code to compile, but WinRt doesn't seem to like it being run without proper signing.
The IDE won't happen for a while, not yet at least. I'm sure that with proper signing, it is possible to run a compiled executable.
Or the other guy might be right and it isn't just an issue of signing.
I've ported SharpDevelop to run on unlocked Windows RT devices, it works at least for C# Windows Forms apps. http://chentiangemalc.wordpress.com/2013/03/18/sharpdevelop-rt-edition-beta-code-windows-forms-directly-on-windows-rt/
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()