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.
Related
Short backstory, I need to create an App for my computing coursework, and since I'm quite the procrastinator I wanted to make an app that shuts down processes that users waste time on.
Therefore I looked up how to make Windows 10 apps and stumbled across Microsoft's own "C# Fundamentals for Absolute Beginners" and "Windows 10 Development" for absolute beginners. I spent over 20 hours watching these videos over the past few weeks.
Now I have designed nearly all the UI in XAML over the past few days and now when working on the Code behind in c# I noticed that System.Diagnostics.Process could not be found, I tried to work out why and eventually stumbled across this answer which made my jaw drop (TLDR it's because it's a UWP app): Missing reference to System.Diagnostics.Process
I do not need my app to run on the Windows Store, all it needs to run on is my computer however messy the solution may be, but I really need access to that class to shutdown processes. I really want to make the app in C# and XAML though and I'm not sure if I can do this whilst having access to the System.Diagnostics.Process class.
I am really running out of time for this project and I can't just change my idea as the problem definition essay has already been marked, etc and that would take forever to rewrite.
I am open to the idea of just writing the application fully in C# if there's really no way I can use XAML without making a UWP app. But I'm not sure what's the easiest way of doing this/what project type so any help would be appreciated.
I feel very angry at Microsoft for not making it clear that "Windows 10 Development for absolute beginners is" actually "Windows Store Development for absolute beginners". I do not want my app on the Windows Store so if I could force reference the process class that would be great!
You need to develop a Desktop app (WPF). With WPF you also use C# and XAML, however you can use all .Net Framework.
UWP (Store apps) need to run in devices like Surface RT (Windows RT), Lumia 920 (Windows 10 Mobile), XBOX and Hololens so they use only a part of the full .Net Framework (they use the .Net Core Framework). UWPs run in a sandboxing so they usually don't have access to system APIs (low level access like create a IP package). In this case you should use WPF.
Your problem is one of the reason, I think that StackOverflow use the tag uwps and win-universal-app.
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.
Since WinRT have unique capabilities, I wonder if it were to make a Windows Service that is targeted to WinRT? If it were not possible, is the workaround to make an invisible WinRT/Metro application possible?
Thanks a lot.
No is the correct answer. A metro application executes inside the Metro shell and inside an execution container that creates a sandbox away from system resources, including services. For this reason a metro app cannot access a local service. Similarly, for this reason, a metro app cannot be a service.
Background tasks and push notifications through Windows Notification Services are the only way for a metro app to interact with the user while not active. Otherwise, when the application is not active (not visible), all of its threads are suspended (unlike a service).
As for background tasks, their activity is constrained identically to a metro app and limited to a single CPU second every 2 hours (there is one exception). Push notifications can execute more frequently, but are only capable of updating a tile or raising a toast notification.
The intent of a metro application is different than a traditional desktop application:
Metro applications are architecture independent (run on intel or arm). Metro applications are touch-reach, built for touch screens. Metro applications are fully hardware accelerated. Metro applications leverage the next gen hardware that certified devices offer, including unprecedented battery life. Metro applications are the only applications delivered by the Windows store.
Look, choosing a metro application does mean to concede some of the unlimited power of desktop applications. However, the gains are significant, too.
Nope this isn't possible (wither the service, or the "invisible" metro application).
You can run background tasks that may do what you are after, but without understanding your problem I couldn't say.
It depends on what you want to do.
WinRT is an API and can be accessed from Metro (Windows Store) Apps and from Desktop/C# apps.
However not the full API is exposed - see what you are allowed to access here: http://msdn.microsoft.com/en-us/library/windows/desktop/hh920511%28v=vs.85%29.aspx
Hanselman shows how to add a ref to WinRT:
Edit the csproj:
<PropertyGroup>
<TargetPlatformVersion>8.0</TargetPlatformVersion>
</PropertyGroup>
Then add a reference to Core/Windows.
http://www.hanselman.com/blog/HowToCallWinRTAPIsInWindows8FromCDesktopApplicationsWinRTDiagram.aspx
We want to write a client for an online service which should be available on as many platforms as possible. This question is about what programming language and framework we should use to create this client.
These platforms are required: Linux, Mac, Windows, iOS (iPhone, iPod, iPad) and Android. The more the better.
For the mobile platforms there is Titanium Mobile. I haven't tried this thing yet, the website says you can develop for both iOS and Android using web skills such as Javascript. I don't know yet if you can deploy for both platforms using the SAME code. It would be great!
There is also Titanium Desktop but I don't like the idea that the complete source code is shared with the final application. Titanium does this for Mobile too but it isn't that easy to modify an app loaded via App Store.
So, what other way is there to create an application which runs on at least the three major desktop platforms? I thought c# with mono would be the way to go but I just realized that you need to use mono with MonoMac in order to publish it on the Mac App Store and use things like Growl. And since MonoMac is naturally only available for Macs, it's again not possible to deploy the mono app on all platforms without rewriting it for at least the Mac. And it would be nice if the app looks "native" on all platforms. Gtk# just does not look good on a Mac. It's "okay" on Windows and great on Linux.
I know we could use Objective-C for iOS and Mac, Java for Android, C#.net for Windows and C#.mono for Linux but the main point is that we don't want to write the same app in a lot of different languages. That would make development and maintenance really hard.
And we prefer languages with C-style syntax which are much easier to learn for us PHP web developers. Btw: We dislike Air and I'm not sure about Java since I never used it but it also does not look "native" and it feels kinda slow.
Edit:
Just a note: It wouldn't be a problem to create an own form for each platform if at least the remaining code is the same. Is it possible to use MonoMac, Gtk# and Win Forums in the same C# application? And I'd prefer C# over C++ as I have no skills in C++, so I first need to check how hard it is to write with Qt.
Another note: We don't plan to spend much money and because we need to pay Apples Developer Programs we want to use free or cheap technology. Preferable Open Source.
Just use C# for all of the above.
The mono project will cover Mac and Linux, with monodroid your android requirements are covered and monotouch will take care of iPod/iPad/iPhone.
In regards to UI - mono has full support for the System.Windows.Forms namespace, so you don't have to use GTK# if you don't want to.
I don't think I need to mention windows support ;)
If you really want to support all those platforms from a single application, your best bet will be to create a web application. With HTML5, such an application can even be cached on the device and used when no connection is available. Also, that strategy would make it feasible to customize the UI based on the device running the app.
You will not have good luck if you set out to build a single native app that runs on Android and iOS, let alone all the other platforms you mentioned. The reason that they're different platforms rather than the same is that they're, well, different. They have different capabilities, run on different hardware, are built with different languages, employ different application models with different user interfaces, and have audiences with different expectations.
The best solution I've come across over the years is Qt SDK.
Great support for all major platforms, Symbian, OS X, Linux flavors, Windows, Windows CE (mobile), Android and iOS partial support and etc.
Its base is C++ but bindings for almost every language (like C#) is available. Lots of help and support is also covered.
The core Qt libs are very fast and extensive, And the whole KDE desktop (of Linux) is done with it. Famous software like VLC and VirtualBox are done in Qt.
Another relatively new way of doing cross-platform development is to use the open source Eto.Forms, which allows you to have one UI codebase target each platform's native toolkit. It is a UI abstraction layer that can target GTK#, MonoMac/OSX, WinForms, and WPF.
There is also an iOS port in the works.
Java sounds like the best fit. It is cross-platform, easy to understand, has a huge userbase and android is based on it.
Depending if you need an offline interaction mode, it sounds like you should develop a web application. You can develop a mobile version and a desktop version and thus support all the of the above platforms. Look at youtube's application for Iphone, it retains the same functionality as the the iphone app but is purely html. Furthermore, html5 capable browsers could also have the ability to run offline.
Crazy as it sounds, check out Flash/Flex - it is cross platform, code once, run everywhere ,now compiles down to native code on e.g. Android and iOS and the 10.1 player is shipping all over. I had to solve exactly this problem and when Flash Builder Burrito catered for mobile after working with it for a while I have switching from C#/Flash hybrid to Flash only for clients. (Our backend is C#/Node/C++, etc).
Depending on your timelines and needs it is something look into.
Some random links to peruse:
Blog post about performance and video to single app multi device
Developing flash and flex applications
The new Windows 7 taskbar features, like jump lists, previews, etc. are really cool, and I want to allow my C# applications to use them. I have two questions:
First of all, how can I use these functions (in general)? I found two articles by Microsoft about this, but I'm not really sure what to do. Could you provide links to a library, as well as some sample code?
Next, let's say that I figure out how to use these Taskbar functions. My question is, is there some built-in way of checking whether the OS is Windows 7, and thus enabling the taskbar functions? If I didn't have this logic in my app, would it have problems if it was run on a non-Win7 machine?
Thanks!
In the first article you link to there is a sample library that you can download that makes use of the new Windows 7 features.
This article shows how to check the version of Windows your application is running on.
As always, if you call an API that isn't in existence, then yes, your app will experience some turbulence. Remember, it's (almost) always better to check for a condition and act accordingly once (as in application startup) than to try something over and over in code and catch exceptions.
Windows API Code Pack for .NET Framework is your one stop shop for a ton of .NET API for Windows programming, including Taskbar. This library gives you a complete API set to work with Windows 7 Taskbar and then some. It also includes samples for WPF, and Winform.
Another good source for Windows 7 content is the Windows Team Blog