I am developing a VB.Net based Windows8.1(10) Store application.
After published, I've found out that my App crashes on Windows8.1 while it works fine on Windows10.
So, I want to debug my App on the Windows8.1. However, I cannot find how to do so.
When I [Run] the App to [Simulator], it runs on clone of my computer, but I want to run it on other version of Windows.
Visual Studio 2015 is now installed on Windows10.
Thanks.
Disclaimer: I work on Visual Studio, though not on the Universal/Modern App area.
This is not a supported scenario and there is no feature present in Windows that emulates or simulates previous versions of the "Modern" runtime environment.
The Simulator feature is actually a local-loopback Remote Desktop (Terminal Services) session and existed to make it easier to debug Modern applications given that they could only run in a fullscreen mode, however as this is no-longer the case (as apps are now floating windows) the utility of the Simulator is limited, and as you're discovering is not relevant to your problem.
The only solution I can recommend is to use Hyper-V (or another desktop virtualisation product, such as VirtualBox or VMWare if you don't want a hypervisor installed) to install a dedicated Windows 8.1 environment followed by installing the Visual Studio Remote Debugger.
Given the rapid adoption of Windows 10 (as it is provided as a recommended update to the majority of Windows 8.1 users) I don't personally recommend explicitly targeting the Windows 8.x "Modern" app environment unless you know you will have users or if it's a contract requirement.
Related
Given that the iOS emulator only runs on OS X, what are reasons that people do MonoTouch development on Windows? They offer MonoDevelop for both Windows and OS X.
Some people prefer Visual Studio. Some teams may have invested in tools (like ReSharper, etc) that run in Visual Studio. And teams that maintain other .NET projects may not to switch to Macs as their primary environment.
The idea of only being able to place an app using ONLY the mac tools is not ENTIRELY correct. You are completely able to use the iTunes connect website https://itunesconnect.apple.com/WebObjects/iTunesConnect.woa/wo/4.0.0.7.3.0.9.3.1.1 to place apps on the app store, and you only need the xcode tool for stuff like using the simulator and other options such as that. The reason why people do things such as program on a Windows is because some people are more native with the way the UI works on Windows than on a Mac, as they are quite different. The Windows is more visual, and it offers a simple way to get to things; although the Mac is more user friendly when it comes to the way applications are handled in the core of them. Also, people don't always want to pay the 1200+ price for a Mac machine, when yet they can spend 200+ on a simple Windows OS machine, and still possess the same kind of options. Another thing, you can always run Windows through a mac, so it's kind of a positive negative situation in almost any circumstance.
Hope this helps!
My personal reasons for using Visual Studio currently for my iOS development are:
I'm doing mixed-client-and-server development, and have a single solution with several project types which Xamarin Studio doesn't yet support - or which it only partially supports:
Portable Class Libraries
Azure website projects
WindowsPhone projects
WindowsStore projects
Resharper and the Visual Studio productivity tools and are key parts of my toolchain - they really do make me more productive. (There are other tools too which I'm more familiar with on the PC - e.g. even things like notepad++ and Paint.Net)
Because of my last 20 years on Windows I'm faster at working on the PC - although I am getting quicker at using the Mac.
Background
We're using System Center 2012 to deploy a Windows 8 Metro-style application to Samsung slates in the field running Windows 8 Enterprise x64. The slates are joined to the domain and have a persistent DirectAccess connection back to it, allowing System Center to push applications and updates to the devices.
We have to deploy our application to potentially hundreds of devices in the field, which is why we went the System Center route. The code signing cert is installed on every device using Group Policy. To deploy the application, you simply provide the package output and specify the collection of devices to install it on. The app just shows up on the device in a few minutes.
The problem we're having is that when System Center deploys our application, the SQLite dependency is lost and none of our data access works.
About our project
Our application is a WinJS application that uses SQLite as a backend. However, all our data access code is in a C# WinMD project which the WinJS project references. We're using the sqlite-net library to talk to SQLite - we included the source for that in our C# project.
In Visual Studio, we installed the SQLite for Windows Runtime extension as described in Tim Heuer's article. The Metro application references this.
Testing using other deployment methods
SQLite data access from the application works fine when you debug or run it locally - in both Debug/Release and x86/x64.
The app packaging process provides a PowerShell script that you can use to install the application and a developer license if necessary. When installing our app using the PowerShell script, SQLite data access also works fine. Verified this by packaging and installing both Debug/Release and x86/x64 versions of the app.
Troubleshooting
When the application first tries to use SQLite, we see an exception about it not being able to find the sqlite3.dll.
We've tried/verified the following:
Confirm that we're deploying a Release/x64 build
Examine the appx in WinRAR and verify that it contains the sqlite3.dll
Reference the "SQLite for Windows Runtime" extension from the C# project instead of the WinJS project
Also reference the C++ runtime, this caused System Center to fail when deploying the app. Don't know why yet, but looking into it.
UPDATE
The issue is that System Center is having trouble deploying the Visual C++ Runtime Library dependency that the SQLite library needs. So unfortunately this isn't a programming question anymore. We're getting some help on this and I'll post the fix.
I wanted to post the details of a temporary fix that we're going with. We've also gotten closer to the root of the problem, so I wanted to provide those details as well.
Recap of Issue
When referencing the Visual C++ Runtime Package from our Metro project, System Center is unable to deploy the application to the devices because there is a problem deploying the proper version of the dependency for the appropriate architecture and build flavor.
Our development machines running Visual Studio 2012 (and packaging the project for deployment) are using a newer version of the Visual C++ Runtime (50727) than what is available in a fresh installation of Windows 8 (50712).
Worked with the System Center team and confirmed that this was a bug in the version we were using and has already been addressed in future builds. We're going to work on upgrading the environment but that will take a couple of weeks.
Workaround
I confirmed and tested the following workaround:
Remove the reference to the Microsoft Visual C++ Runtime Package from the Metro project
Install the x64 version of the Visual C++ Redistributable for Visual Studio 2012 - http://www.microsoft.com/en-us/download/details.aspx?id=3
Deploy the application
Works like a charm because the correct version of the dependency is there already. Obviously not a long term solution if we choose to also target x86 and ARM, but will get us over this hump.
There's no emulator for Windows 8, so in order to develop metro apps I must install the release candidate on a device and run Visual Studio there, right? That's what this page seems to suggest, but I just wanted to double check.
Yes, Windows8 is required.
However, VM can be used. For example, I'm running Win8RP/64 and VS2012RC in Oracle VirtualBox on Win7/64.
NOTE: For developing Metro Style App, you should NOT install VirtualBox Extension Pack.
Yes, you need Windows 8 to develop Windows 8 Metro style apps.
Metro Style apps rely on a new set of APIs which are implemented only in Windows 8 through the the Windows Runtime (WinRT).
There is no emulator for Windows 7 and not even for Windows 8... Windows 8 has a simulator which in practice is just a Remote Desktop session to the same machine. It is not an emulator.
While Windows 8 is not in its final version, what I recommend is to install Windows 8 in a VHD (virtual hard disk) and boot your PC directly to the VHD. It is faster than running virtual machines (because only the disk is virtual, all the rest is real hardware) and you can keep your Windows 7 intact.
This is what I've been using since Developer Preview. I have a dual-boot configuration being one for the Windows 7 that is booting from the regular disk partition, and one Windows 8 that is booting directly from the VHD on disk.
Metro UI style is just a design approach and some guidelines. You are free to implement such interface using Visual Studio 2010 as well as 2008. Using C# and WPF everything is possible. But, indeed, new Visual Studio has a set of Metro style components (WPF) with which your development process will be much more quicker.
The only thing you can't use at OS other than Windows 8 - is WinRT subsystem.
Almost all of the development tools needed to build Metro style applications can be run on OS's other than Windows 8 (Visual Studio and the package creation tools require Windows 8). So it should be possible to set up a build environment using msbuild.exe (or even make/nmake) that will compile and link metro-style applications on an OS other than Windows 8.
However some parts of development MUST be done on Windows 8 - the tools for some of the steps of development will only run on Windows 8.
I want to know whether Metro Applications developed using Visual Studio 11 Developer Preview and .Net FrameWork 4.5 can run in Windows 7 or XP.
Not the normal Windows Form or WPF, I want to know about the all new Metro Apps.
What new things needed to run Metro Apps in Windows XP or Windows 7
What new things needed to run Metro Apps in Windows XP or Windows 7
A virtual machine of Windows 8. Metro apps currently don't run on Windows 7, and definitely don't on Windows XP. According to this thread, it's difficult but might happen eventually:
Keep your eyes out on future Channel 9 videos and on the BCL/CLR blog
for more information around the challeges of enabling the Portable
Library story, however, I will give a quick summary with regards to
ViewModels:
While the ViewModels themselves are defined by the
application, they often take dependencies on types (ie
INotifyXXXChanged interfaces, ICommand, etc) that live inside the
framework. Currently if you look across our multiple .NET platforms
(Silverlight, Phone, .NET and now Metro style apps), these all live in
different assemblies, and with Metro apps, a different
namespace/technology (WinRT). This makes it challeging to give the
user a surface area that can compile against and still have it run on
all these other platforms. We've got some ideas on how we're going to
enable this, however, it requires some work and doesn't come for free.
In saying that, however, we completely see the value and
really, really want to do this.David
But it's not currently possible. At best, you could just make a desktop app version of the same thing.
I tried it on Window 7 and answer is definitely no, you can not even develop Metro style App in Windows 7, for developing also you need Windows 8 and Visual Studio 11.
I'd be astonished if Win8 Metro-Style apps would ever work on Win7 - there is a huge amount of OS level infrastructure necessary to get those apps to work on Win8 that simply isn't available on Win7.
Having said that, people have figured out to write applications that can be made to work on both *nix and Windows with a recompile, so I imagine eventually it might be possible to write an app that could be recompiled to produce a metro-style version and a WPF/Silverlight version. But that technology simply doesn't exist at the moment.
Id say no, based on the fact that Metro requires WinRT which is not available on Windows 7 or XP
This depends on what you might want to do.
For example, if you're developing a game and want it to run on Metro/Modern UI but also on other Windows versions, MonoGame is a great option!
It will allow you to develop for and run on:
All Windows desktops
Windows 8 Metro/Modern UI
Mac OS X
Linux
XBOX 360
iOS
Android
Windows Phone
And possibly more platforms on the future.
In my honest opinion having such a wealth of target platforms warrants any learning curve you might have to develop for MonoGame. And not to mention that you can develop in the comfort of Visual Studio, so IMHO it's something to be considered even if your app is not strictly a game (who said you can't develop a non-game with a game framework...?).
Update: Here's a tutorial, and by the way, you may want to also consider HTML5 for games or non-games. Cut the Rope (very fun game) uses this, and it seems to be doing pretty well (I didn't even notice it was HTML5!).
I am developing an app for the apptivate.ms contest right now. So I can definitely tell you that the Metro apps won't work on Windows 7 or XP.
What is more, the Visual Studio Express version needed for developing the Metro Apps won't even install on Windows 7.
Also, just remember this sentence - "All Windows apps are not Windows 8 apps!"
Is there some kind of SDK out for WinRT.? Can we develop applications for it now?
Is VS2010 usable for developing or will some other IDE be shipped? Also, is C++ necessary to develop performance-oriented apps in WinRT, or will the C# applications give equivalent performance? Can development be done on Win7?
I am curious about this because I missed out when WPF was released and I don't want to miss out on this.
Take a look at the Windows Dev Center where you can download a copy of Windows 8, complete with all the new tools for developing for it.
Visual Studio 11 Developer Preview is also available on Subscriber Downloads if you do have a subscription, and it includes the WinRT SDK and runs on Windows 7 and other operating systems. So you can build it and debug it, but you still have to run your code on a Windows 8 machine.
Performance-wise, WinRT doesn't change the guidance for whether to use native code. The APIs will behave near identically regardless of what language you choose, so make the decision between C++ and C# just as you would today.