The title is all-explaining I think. I want to develop .Net GUI application for Windows that will also run on Mac with no much extra effort. I guess WPF is not right choice here. Anyway, what do I do to make my Silverlight out-of-browser application to run on Mac ? Just install Silverlight on that machine ?
Silverlight's Out of Browser model works great on Mac, and has since its inception. Just develop the app and test it on Windows, it's basically guaranteed to act identically on Mac, unless you rely on a Windows-only feature (such as COM interop in Silverlight 4 Trusted Applications).
Edit: To further clarify my answer, nothing beyond the Silverlight Runtime install is needed to run OOB apps on a Mac. So if the user is able to run you app in-browser to do the install sequence, then they will be able to install the app OOB and use it.
This works with Silverlight 3+ only, of course, as that's when the feature was released. SO if the end-user has Silverlight 1 or 2 installed, they won't be able to install your app, but they could upgrade to the latest runtime to be able to do so (unless they're on a PPC Mac, as that only supports Silverlight 1. But most Macs these days are Intel anyway, so that's not really worth mentioning).
According to Getting Started with Silverlight 3, OOB is available on both Windows and Mac without an additional runtime. Here's a demo of the install process from channel9.
As far as specific hangups, that's beyond my experience. But it sounds like, in general, there are no special requirements to run SL apps out-of-browser on OS X.
I have built a state wide Silverlight 4.0 application that runs in browser and out of browser. In my experience it runs very well on a Mac, however I would say that it's not exactly the same. It's very close, but there are small differences in the install experience, and I've received some errors in Isolated Storage that I don't get on a Windows machine.
Overall I would definitely say Silverlight is the best cross platform development platform that I've ever used.
Having built a SL app for OOB on mac, I discovered one bug that gave me hard time. If you are using domain services, and have a method that try's to get the current authentication context to pull the userID on the server side, this will fail. It will work on Windows OOB, but not on Mac OOB.
The work around is pass in the userID from the client side to the domain service queries that need it.
I've had this issue using the standard SL Business app template and confirmed with various users on SL forums.
Related
I'm trying to make a UWP App where users have to log in to my website (a hypothetical one as of now). I want the user to be able to run the App while logged into the website without having to download the App to their own computer. I want this website deployment to work in web browsers beyond IE. Is this even possible?
You'll be surprised to learn about UNO which is a platform promising UWP everywhere. You can run your UWP app inside a browser (using WebAssembly), Android, iOS, and of course natively as UWP on Windows 10 devices.
https://platform.uno/
Please be aware that as far as i know this is not production ready so you should expect issues, bugs, and weird behavior. Their gitter chat room is somewhat active and the team behind is responsive. But be warned.
I am looking to write a simple app which accepts input from an Xbox 360 controller. I am developing in C# and my current dev environment is a windows 10 machine.
I've attempted to install XNA studio 4.0, and got a system notification saying that it isn't supported. When I clicked on the notification for more info, I was redirected to a webpage which started a Windows Live Gaming installer download.
This seems to rule out XInput.
I thought my alternative was to use the Windows.Gaming.Input namespace, but it seems to be limited to metro apps.
I don't know what are my other alternatives.
What is the correct library for me to be using, and where do I download it from?
XINPUT will read the Xbox One controller with the drivers currently on Windows Update, but you will be unable to access the 'impulse trigger motors' using that API. For C# usage, look at SharpDX or SlimDX.
You can use Windows Runtime APIs from desktop apps including Windows.Gaming.Input. They key is you have to initialize WinRT with Windows::Foundation::Initialize.
See DirectX Tool Kit: Now with GamePads. If you were writing in C++, I'd also recommend looking at the DirectX Tool Kit GamePad class.
Apologies for the noobish question, and I did try to search but couldn't find the right answer (or didn't search properly).
Currently have an app developed in a windows desktop environment because it gives us access to deeper features of the PC such as serial port comms etc. that the normal metro environment wouldn't allow. We're currently developing the UI based on metroUI so we can run it on an 8.1 touchscreen (metroUI looks good, gives us a touch-screen experience with PC features) but we have no intention of putting it on the marketplace.
Just wanted to confirm if this is in fact doable, and we can have this desktop application with a metro UI? Or is my noobishness meaning I'm overlooking some technical feasibility that makes it impossible?
This is doable with the Windows 8.1 Update (from April 2014). It's not supported before that since Windows Store apps were blocked from communicating with desktop processes.
The Windows 8.1 Update adds a feature "Brokered Windows Runtime Components" designed to allow side-loaded Windows Store apps to communicate with a desktop back-end. This will allow your Windows Store app UI to call the desktop component to access API that aren't available in the limited app package environment.
See Brokered Windows Runtime Components for side-loaded Windows Store apps for details.
See Try It Out: Sideload Windows Store Apps on TechNet for how to enable side-loading on your systems. See Windows 8.1 Update: Sideloading Enhancements for updates on how to enable a system for sideloading (no license required when on a domain, and significantly easier to get a sideloading license for non-domain joined systems).
The developer license system is designed for development and test purposes only. You really don't want to use it for production. Use the proper enterprise side-loading system instead.
From my understanding, the whole point here is to make it look like a Windows Store app. If you're app is a WPF one, you can already use Mahapps.metro.
You can create a Windows Store app without going to the store by Sideloading it. You create an app package first. The user has to right click the .ps1 file in that package to see the option Run with PowerShell and install it in a very old fashioned DOS like manor. It will only run when the user has a Microsoft Developer License and renew it every month. However, it is not allowed to keep using a Developer License of the end user to run a Store app. In the end, the system has to be domain bound to be allowed to run these apps, or you have to buy a Enterprise Sideloading key. These come in packages of 100 for $ 3000,- or you can unlock all PC's for 1 client for $ 100-.
It would be nicer if the specific pros of a Store program were available in a desktop environment but with W10 coming up I do expect a bit more integration and less restrictions.
Hope this answers your question.
I have a little bit stupid Question!!
I'm writing a little application with C# and the Network programming work with Windows PC's.
I watch some newbies Tutorials from Microsoft that's why.
So now i just want to know, how i can program so that my application can connect to all PC's or Mac not regarding the OS(Win, Linux, Mac OS).
It's possible? when yes how?
Thanks a lot for Helping!
You can use mono to develop in C# and deploy your application to Windows / Linux and Mac OS.
You can use a web service, and your client application on other OS's can all connect to a webservice and use it, even if you end up developing your clients in another cross OS language like java.
On the other hand you could use tcp/ip, or udp protocols depending on your application needs.
It really depends on what you are doing.
If you want to have your application running on different PCs and then they talk to each other then yes, have a look at Mono. Basically it means you can write your program in .NET and then run it everywhere where an implementation of the .NET platform is available (Mono supports Windows, Linux and Mac OS).
Otherwise you need to specify as to what your application wants to connect to.
They solved this problem and the solution was web services.
If you want TCP/IP that's another story.
I've been writing desktop apps in C# for some time now but I'm increasingly getting frustrated with the fact that not everyone has .NET 2 or Higher installed. I don't have the option of upgrading their systems to meet my needs. My apps are mostly utilities that run alongside the main program the company I work for has. They access the file system and the registry. Being relatively new to programming in general, I was wondering if moving these tools to the web would solve some of my problems. But I have no idea if web apps can have access to these parts of Windows. I was thinking of writing these web apps in either Rails or ASP.NET. So my question is this. Can a web app access and modify the registry and file system of Windows?
Thanks.
Nope, "web apps" like asp.net or rails apps run on the server alone and just serve html to the client. So all the client-side code can do is what jscript running in the browser sandbox can do, ie no file access or registry access.
You can however install an activex on the client computer that gets full access, but the user has to agree to install it as it's a security risk.
Writing the apps as Web apps instead (and Rails is cool to use) is a good option - your users don't need to install anything, upgrades are easy to do, and dependancies are no longer a problem.
However, you now need to start re-architecting your apps so they do not need to write anything to the client, except a cookie (that's stored in the browser). If you can do this, then migrating to a webapp will be great.
If you cannot, my advice is to learn the same language that your company's app is written in. Once you do that, the company app will have taken care of the dependencies already and you will just need to offer your utilities alongside the app, perhaps even in the installer, or just to copy the files into a subdirectory. If you're thinking of learning Ruby, then learning the corporate language will be just as difficult (only you'll be able to reuse a lot of code used in the main app)
No, a traditional asp.net application cannot access the file system or registry on the windows box. Simply put because it doesn't actually run on the client machine. Instead it runs on the server where it does not have access to the local machine.
It is possible to have portions of the application which run on the client machine. Browser based applications for instance. However these would require that the 2.0 framework be installed on the customers machine which puts you right back at square #1.
No, this isn't possible. Web applications cannot modify the registry and/or file system on a user's machine because of the security implications. You would need to develop a Windows app to do these kind of changes. You could always make this tool available for download on your website though.
No, you can't do that with a web application. Besides others have already said, a web application run in a browser, not inside an operating system, so all you can do is what browsers allows you to do and not all you want, and browsers doesn't allows you to take control of the host machine.
I'm guessing the desktop app used in your company uses the registry to store workstation / user specific (state)data.
Moving to a web based app does not mean storing state data is no longer possible, just account for it by including a table in your database that can be used to save that same (state)data in. The registry is no longer needed.
Another pro is that by moving to a fully webbased application, you never have to worry about your endusers, because the code is running on the server, all the enduser gets is the output in html :-D.
The only thing to keep in mind is cross browser compatibility, don't create an app that works in IE only for instance, it has to look and work the same in all major browsers.
There are a few products out there, such as Xenocode and VMWare's ThinApp, that allow you to virtualize your app's dependencies to the point where your .NET app can run on a machine without the .NET Framework installed. Just another option from left field.