Is there an AllJoyn SDK for C# / .NET ?
- I want to create an AllJoyn Service in a console application, which have to run on my Windows Server and I only could find the AllJoyn SDK for Windows Universal Apps.
I've started one here: https://github.com/dotMorten/AllJoynDotNet
More or less all of the C API is exposed to C#, but the nicer easier-to-work-with helper classes around it is still a work in progress (but feel free to chip in!)
If you are doing a C# desktop application, as a console app implies, there is NOT one currently. The AllJoyn api coverage in the Win10 universal library is so small as to be worthless for anything but C++ UWP apps so your only option is p/invoke and it is rather tedious. The old version of AllJoyn (14.x) had a C# .Net wrapper but it was removed as it was apparently not maintained. The code can be found in the AllSeen Alliance git repositories but updating it for the newer apis will be tedious.
Yes it is there...at least for Win10 Universal (and IOT)
In VS2015 you have project templates as well as you can use "AllJoyn Explorer" (can be found in the link below)
Check it out here
https://ms-iot.github.io/content/en-US/win10/AllJoyn.htm
Related
I've developed a WinForms application with C# in Visual Studio on Windows and I need a version for macOS but I don't know which way is the best.
I also have a Mac machine so don't have problems about the compiler: I already used VS2017 with integrated Xamarin to develop an iOS app using my mac as the required build server but didn't find any such method for developing a Mac desktop application. NET core only works with console application and even Visual Studio for Mac is different from Visual Studio for Windows and doesn't provide any visual designer. Am I forced to redo the whole application using an Apple product?
There are multiple solutions to building desktop apps targeting a Mac using .NET.
Mono is an alternative implementation of the .NET Framework that reimplements the underlying Windows API calls that Win Forms makes. It's probably the most straightfoward way to port an existing Win Forms app to Mac.
ElectronNET is a combination of Electron and .NET. Electron provides a desktop development framework combining a Chromium rendering engine with NodeJS. It's best if you have a lot of familiarity with web development. It's notable that major companies that want to build cross platform apps are using Electron (Visual Studio Code, Slack, Atom etc) so those with the time to invest in researching how to do a cross platform app seem to choose this option.
Avalonia is a .NET desktop framework that is inspired by WPF, but it's cross platform.
So no, you aren't forced to redo your application. Hopefully you've done a good job of separating UI logic from business logic, which will make using one of these other technologies easier.
Note that even though .NET Core 3 (which is cross platform) has support for Win Forms and WPF, that functionality will only be working on Windows. Win Forms still depends on the underlying Windows APIs, and WPF still depends on DirectX.
So I was working on a project that needs a .net 3.5 framework API. So since I can't use the API directly I decided to use communication using a bridge between a UWP/WPF app in order to use the API.
Now I have followed the steps in here: https://mtaulty.com/2016/10/12/windows-10-1607-uwp-apps-packaged-with-companion-desktop-apps/
So when launching the app from the exe directly it would work fine. However if I am to launch it it is unable to load the API.
Any idea of what I can do to deal with it? Or is there a better way to implement a .net 3.5 api in UWP?
Why does FullTrustLauncher stop the app from working correctly? Would packaging the APP in something like ILMerge help?
Or are there any ideas I can do to deal with this issue?
Edit: here is the sdk I have been using with its documentation
http://sdk.emiratesid.ae/page/Downloads.aspx
It also contains sample projects in forms however as mention the issues arise when porting to uwp
I work for a team that currently specializes in creating windows desktop applications in C#/.NET that interwork with local user instances of Microsoft Excel via Office COM Interop. I am currently charged with specifying a new product but I’ve been told that the project will not go ahead unless the app can run on Mac as well as Windows – that is, we have to be able to produce a Mac version of the app that can install natively on OSX and interact with the object model of a user’s instance of Microsoft Excel for Mac.
Running the app with Parallels, Mono or Wine (see COM Interop Through Wine in OSX, which was never answered) is not a solution because the spec for the app requires that the user machine is not modified in any way. We just have to assume the user has a licenced local copy of Excel running, and work with that… which is what we have always done on Windows, where it works great.
I think .NET Core is the answer but I can’t find anywhere where it says definitely that we can (or will be able to) access the Excel Object Library from C# when running .NET Core on Mac OSX with a local copy of Excel for Mac installed. Can anybody point me please to where this has been discussed already; but if not, then tell me how I can go about finding out from Microsoft if this is in their roadmap for .NET Core?
I have received some helpful feedback from a similarly worded question on MSDN. I have also posted an issue on the .NET Core Github, but I think it is already clear what the answer is to this, which is as follows:
The .NET Core team may perhaps be persuadable to add access to the Office.Interop.Excel namespace in the .NET Core Class library, but only for Windows
This cannot be done for .NET Core on OSX because the environment is
not suitable for interchanging COM objects.
This leaves only two options for manipulating objects in Excel for
Mac, both of which already exist: Embedded VBA or Javascript (Office
Add-ins).
Office Addins is a great new solution for web-driven data-oriented
objects in Excel - and its multiplatform nature is awesome - so is enjoying the main focus of
development from Microsoft. However it is not intended to be any
match for the performance of COM for managing complex spreadsheets,
since that's not its focus.
Which means there is no solution for managing objects within Excel
for Mac using C#, in the way that there is on Windows, and there
doesn't appear to be any prospect of one.
The bottom line: The very welcome .NET Core initiative looked like it was a fix, but sadly isn't, because of architecture limitations on OSX.
I have submitted this as an answer because I think I've come to the end of the line of enquiry on it, but if anyone thinks any of the above is incorrect, please shout!
Thanks.
I have an app developed using Xamarin.iOS that i would like to port to Windows 10. I have read that is possible to use Windows Bridge to port app developed using Objective-C (WinObjC provides support for iOS API) to Windows 10 using WinObj project.
It's possible to do the same with a project written in C# using Xamarin.iOS?
If you're working with Xamarin.iOS you need to forget WinObjC. WinObjC is a bridge to write native windows apps using Objective-C. Since you're using C# you can write the interface using XAML and share your business logic between the apps easily.
The WinObjC project is a bridge of Cocoa Touch, not a port, and it's real Objective-C. You would have to convert your C# code to Objective-C by hand, yes. Eventually you'll be able to use (mostly) the same source code on iOS and Windows!
Using the Windows Bridge for iOS to bring your Xamarin.iOS App to Windows is not working. This only works with Full Objective-C Projects. Anyways you will be able to build your Windows App on top of Xamarin.iOS very fast when you have encapsulated it correctly. Then you just need to rebuild the UI and maybe implement some interfaces :)
WinObjC is the Windows Bridge for iOS (previously known as ‘Project Islandwood’).
Windows Bridge for iOS (also referred to as WinObjC) is a Microsoft open source project that provides an Objective-C development environment for Visual Studio/Windows.
In addition, WinObjC provides support for iOS API compatibility.
The bridge is available to the open-source community now in its current state.
The iOS bridge as an open-source project under the MIT license. Given the ambition of the project, making it easy for iOS developers to build and run apps on Windows. Salmaan Ahmed has an in-depth post on the Windows Bridge for iOS http://blogs.windows.com/buildingapps/2015/08/06/windows-bridge-for-ios-lets-open-this-up/ discussing the compiler, runtime, IDE integration, and what the bridge is and isn’t. Best of all, the source code for the iOS bridge is live on GitHub right now.
The iOS bridge supports both Windows 8.1 and Windows 10 apps built for x86 and x64 processor architectures, and soon we will add compiler optimizations and support for ARM, which adds mobile support.
I need to develop Metro style application using C# and XAML which has to work on Windows RT devices and full Windows 8 OS. So I'm allowed to use only WinRT without any .net framework assemblies. I've read this question
Microsoft Surface Tablet: Writing Apps for Both Devices?
and this very usefull post: http://blogs.msdn.com/b/jasonz/archive/2012/06/12/what-you-need-to-know-about-developing-for-windows-on-arm-woa.aspx, but i stil have question:
When i even create a Blank Metro Style Application project I have .NET asseblies for metro style. Do I have remove them by myself or i do something wrong? And what i should do if need to use something like Prism fw ported to WinRT or mvvvm light? Are they allow me to develop application for WOA only on native WinRT? These moments are not clear for me.
Can you explain my what the difference between Windows RT and Windows on ARM
Do i need to use only WinRT (without .net) to develop for WindowsRT OS?
Hope you can help me.
Let me answer you in the most direct way I can. If you open a Blank XAML/C# Windows Store project. That project will run on Windows RT (ARM) and Windows 8 (x86/x64). That's because it is built to accomplish this. Just because you have what feels like the .Net Framework, don't worry - you are writing a cross-platform application.
Now, for the caveats. You made this answer easy because of C#. CPP developers don't have the same guarantee because there are coding things they can do to break this compatibility. Not so in C#. If the code you write compiles to "Any CPU" then what I am saying is correct.
If you introduce something (like the Bing Maps control) that requires your build to change from "Any CPU" to something else. The Windows Store will let you submit three versions of your app under the same name - one for each platform - and the user will never know there is more than one.
In that last example, you are still supporting every platform, you just have to specific three different builds to accomplish it – your code may not change at all! In most scenarios, you support them all out of the gate. If you introduce a third party library - like MVVMlite - you are still okay if you can build to any CPU. Most libraries are cool like that.
It's not quite correct to say you can't use the .net framework in Metro style apps. More correctly, there is a version of the .net framework which is only available for metro apps. If your assemblies were not built with this version of the .net framework they will not work for metro. This version of the .net framework will work on .86 and arm. There is also a version of MVVM Light for metro apps. Download it here. See here for details on developing for arm.
Regardless of whether you’re using JavaScript, C++, Visual Basic, or
C#, if you’ve built a Metro style app that targets x86/x64 then you
already know how to build one that targets ARM. You use the same Metro
style project templates, which provide the starting point for building
an app.
Edit:
As Jerry points out, you may have to compile your application against different versions of libraries if they are written in C++, but that's a matter of having separate builds rather than having to do additional development.
If you make your libraries portable class libraries, you can use them for desktop, metro, and phone apps (and xbox too). You can choose this when you start a library, or in the project's properties. It makes it easier to write cross platform apps within the mircrosoft ecosystem.