I am creating a simple metro app. I am also creating non metro version of the same app.
The problem I am facing is that VS is not allowing me to reference normal class libraries into the metro app, and metro class libraries into a normal app.
The differences between Metro and non-metro apps relate to UI, and to some features which are incompatible (eg, FilePicker in metro, and OpenFileDialog in non metro).
How this can be achieved?
The differences are more drastic than you might expect. They are using WinRT as a chance to clean house and remove APIs they don't want to maintain anymore for various reasons. Research "portable class library" which will let you create a dll based on the small intersection of APIs available in the platforms you tell VS to target
Essentially, WinRT is completely separate from the Win32 libraries as Robert Levy mentioned.
In fact, when Windows 8 is being used on ARM devices the Win32 libraries are practically non-existent. Internet Explorer 10 has limited access to them (an Internet browser powered only by WinRT is impractical), but all other metro apps do not.
Metro apps on x86 and x64 also do not have access to Win32, because it is assumed that the same application needs to be compatible with ARM. To reduce complexity Microsoft has essentially said that all metro apps only have access to WinRT. Internet Explorer is an exception to that rule.
What I'm trying to say is this: You'll have to develop both applications separately. Desktop-focused applications reside entirely on the desktop. And metro applications reside only in the metro interface.
Metro UI is not the problem : look "Under the Hood", and you'll discover that the namespaces and the libraries and NOT the same => METRO in NOT another layer above Windows 7 applications.
If you really want to target the 2 environments, create a single class Library with all your business objects, all your databases access, and write two differrents applications call this Library.
Related
I have an app developed for windows 10 on C# and now I want to move to IOS and Android. I have heard of xamarin and used some of there stuff in C# but would it be possible to embed the C# code and move it to apple xcode without having to redevelop the app from again?
would it be possible to embed the C# code and move it to apple xcode without having to redevelop the app from again?
No, it is not possible. Basically you can share some UIs across different platforms, but I think redevelop your app for each platform is necessary.
Not sure if you want to use Xamarin.Android and Xamarin.iOS or Xamarin.Forms to develop your app, you can use C# for development by using Xamarin, it provides a cross-platform implementation of the extensive features in .Net framework, but the actual implementation on each system is very different. For more information, you can refer to Understanding the Xamarin Mobile Platform.
For Xamarin.Android and Xamarin.iOS, you can refer to Android Architecture and iOS Architecture.
For Xamarin.Forms, you can have your UIs and some basic features designed in the PCL in order to share across different platforms, but for most features just for example like working with files, we need to access the native method of each platform, therefor, Xamarin.Forms provides a locator named DependencyService to achieve this.
I want to develop a window application that will have capability to read properties of another window application eg. text boxes, options, buttons, title bar and more. My application would use multithreading as separate thread is always required to activate targetted window.
So, I have found that I should start with win32 API that is common to many windows operating systems but my concern is if the win32 API is supported on Window 7 and Window 8 or 8.1 that uses winRT API.
I actually want my application to run on all Windows platforms.
I have a lot of confusion between these APIs. Please help me understand how I could develop my application.
Win32 has been and continues to be available on all versions of Windows (with small exceptions like Windows RT that does not allow installation of desktop applications). There have been additions to the API between 7, 8, and 8.1, and there are probably also new APIs in Windows 10. In short, Win32 remains a core API in Windows. The WinRT API was build as an addition to Win32, primarily for Store apps but not exclusively. WinRT itself uses Win32, and a Win32 application can use both Win32 and WinRT APIs. Furthermore, desktop applications build with .NET technologies like Windows Presentation Foundation can access Win32 APIs as well.
In short, Win32 is the broadest common denominator for Windows and is a good choice for the kind of utility application you're thinking about.
I have a Windows Phone 8.1 Silverlight application which is in the store now. Since i see that Microsoft is moving all the attention towards WINRT and Universal Apps, i suspect that there will be limited or no support for Silverlight Apps in Windows 10.
There might be a tablet project that i might roll out for the same project in the future. So i am in the dilemma to convert the Silveright projects in my solution to WINRT or convert them into Universal Apps.Also, i hear that converting to Universal projects are pretty hard as well.And I understand that the bulk of the work will be in porting the UI to Hub Style UI.
Any ideas? Comments on the best approach to take here.
A WinRT app is a Windows only app (not for Phone). Other than that, WinRT and Universal apps are quite similar. They have the same namespaces, classes, controls... almost everything. You can use many WinRT libraries in Universal apps without any problem. And so, porting to them is generally the same, too.
Windows Store and Windows Phone apps generally need different UI anyway, so you would have to work on that, no matter what you do.
One difference is that a WinRT app would work on Windows 8.0 and up, and a Universal app would require Windows 8.1 (or WP 8.1 for phones). Actually, a Windows 8.1 app IS a Universal app. Just like a Windows Phone 8.1 app (not the Silverlight variation) is a Universal app.
I'd recommend porting to a Universal app as you would get used to working with these apps, and they work on both platforms (Windows and Phone). For any future project, that's the way to go.
In the company I work for, we switched to Universal apps a few months ago. Figuring out what UI we would use on both platforms and how to do it properly, as well as porting our existing libraries did take some time (not too much), but now making a new app and supporting both platforms is very easy. So, for me, that's the way to go.
It is quite unlikely that Microsoft will stop supporting Silverlight Apps in the Windows 10 version for phones. Even WP8.1 still supports XNA Games from the WP7.0 era.
Depending on the APIs you are using in your libraries the majority of changes when converting from Silverlight to WinRT will be on the UI side, e.g. if your Silverlight App already uses the LocalStorage-APIs instead of the IsolatedStorage-APIs that won't even have to be changed.
My advice would be the following:
evaluate wether all functionality you need is supported in Universal Apps (some functionality is currently only available in Silverlight Apps)
evaluate wether the actual APIs you are using are supported in Universal Apps or need to be replaced (IsolatedStorage => LocalStorage, etc.)
Armed with that knowledge I'd guess you will be able to better plan on when to port your App to the new APIs. If a tablet version is likely in the future and all required APIs are supported in the Universal App Model porting sooner will likely require less effort than porting later.
I am trying to build a Windows 8 "metro-style" app that will operate as a "app killer". For those of you who have used Win8 (Tech Preview) you'll notice that once you open a metro-style app you cannot close it (without going into Task Manager and ending the process).
My challenge is that I cannot access 'System.Diagnostics.Process' from my metro-style app, nor do I know if there is an comparable alternative within the WinRT. I also thought of building a separate app that hosts a service for my metro app to interface with, but I'd like to do this with a single app.
Fundamentally, I am looking for a pattern for building Metro-style apps that leverage .NET 4.0 components, specifically to be able to enumerate and kill other processes running on the PC.
CLARIFICATION: I am less concerned with this specific application than I am with access that type of .NET functionality within a Metro-style app
Thanks
To your specific question, this functionality is not available. Apps are not allowed to interact or interfere with other apps.
To answer your more general question, the APIs available to Metro style applications is limited compared to what is available to desktop applications. C# has a subset of the .Net library available, much like Silverlight does. The same is true for C++ where a subset of the desktop Win32/COM APIs are available.
From what I understand (watching Build2011 videos) a Metro App won't be able to do that...
Interaction between processes is severally limited to specific Contracts (the charms on the right: Search, Send-to).
Think Phone, not Desktop.
You might be able to build a non-Metro Win8 app though.
Don't waste too much time on this. I expect that in a beta a close option (perhaps even a charm) will be included. Until then use a keyboard Alt-F4 or the Task Manager
C++:
Window::Current->CoreWindow->Close();
or
Window::Current->Close();
I haven't explored the difference between these two (more precisely, I don't know how CoreWindow differs from Current. I could assume though...
I'm using an Oracle VBox with Win8 on my Win7 machine to develop a C++ Metro App using VS 11. I used both of the above methods. I verified in Task Manager the app was not running on both Win8 and the Simulator.
I'm thinking of developing a desktop app in C#. Although windows will be my main target, later I'll try and run the app in MacOS X and linux. Can I do this today, in a simple way?
I'm aware of the mono project, but it is not clear to me if I can do this in a simple way.
Also, what is the relation between WPF and Silverlight? AFAIK Silverlight follows a plugin model much like Flash or Java. Can I develop my desktop app with Silverlight and deploy it on windows, linux and os x without much changes?
Any pointers will be greatly appreciated.
The Mono project does not support .Net 3 and WPF yet, and it will probably been some time before that happens.
Silverlight might be sufficient for your needs.
As of Silverlight 3.0 you can run Silverlight outside the browser, even create a shortcut to it on the desktop.
Last I heard, the Mono project has no plans to implement WPF, however they are working on other .NET 3.5 features, especially LINQ and ASP.NET MVC. The problem with implementing WPF in Mono (beyond the size and complexity of the API) is that on Windows it uses DirectX for rendering, so an implementation for Mono would need to use OpenGL. Definitely not a trivial undertaking.
WPF is used to build desktop applications for Windows only. Currently no other platforms are supported. If cross-platform support is a must, you can create a browser-based application and use Silverlight. Silverlight runs applications in the browser, though, so you cannot make a "desktop" application using that.
Mono is working hard to make sure that Silverlight runs cross platform (as mentioned on one of the stack overflow podcasts). So that seems to be a good way to go.