I can't seem to find an answer to this question anywhere, but will metro support managed c++ ?? Right now in Visual Studios 2012 RC it does not (in Metro only).
I have some frameworks written in c++/cli and wanted to port them to Metro. I know c++/cx is similar, but my c++/cli objects derive from ones written in C# and it would suck to have to rewrite that part of my system (but ok if I do, I just need to know where to go from here).
If there are plans to support it when Windows 8 actually comes out, I can wait. Or if not I would like to know now so I can get to work on porting.
C++/CLI is not going to be supported in Metro as you can see here: Windows Metro Forums
Related
This may seem like an absolutely stupid question, but it is one I really need to ask.
I have to find a way to be able to write and run a Visual Basic program on my Mac (Sierra). I have downloaded Visual Studio Community, and have even installed the Mono Project for VB, although honestly I am not quite sure how to use it.
I need to be able to write the VB code and create an editable form to work with it. I will need to compile it and run it on Mac, but I do not have to turn it into an executable.
So, without Boot Camp or Parallels or anything like that, is there ANY way to get Visual Basic, as described above, to work on Mac Sierra?
You can edit code on VS for Mac, but you can't run it. You should do bootcamp or VM Ware if you have a license for an extra copy of Windows.
I have a windows 8 metro game (using monogame) that i developed and plan to submit to windows 8 app store and i wish to obfuscate it. How can i do it? Will obfuscation cause runtime errors?
We use Crypto Obfuscator. It has a very decent GUI, a great support team, and most importantly both Visual Studio integration and support for Obfuscating Windows 8 Store apps.
You can try Manco .NET Obfuscator. Version 4.5 supports obfuscating of the .NET Windows 8 Store applications.
Check the babel obfuscator.
The obfuscator usually "just" makes your code unreadable, alone it won't cause any runtime exceptions but if some occurs (due to an app problem) you probably won't be able to track the error (because everything is obfuscated).
PS: Google is our friend
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Is the .Net framework required for even a single line of VB.Net?
I'm getting my programming feet wet by designing a simple vb .net program to run utilities and installations from a flash drive. I'm making good progress with the coding and design but I was surprised when I went to show off my work on a system with a fresh XP installation and got a "Not valid win32 application" error when I started the exe. Pretty embarrassing actually.
Is having the .net framework installed essential to loading a .exe coded in vb .net? If this is the case, is the only alternative to try and adapt the code to vbs script or something similar? Are there any other reasonable workarounds short of installing .net on the target system? Thanks in advance.
Yes.
It's named VB.Net for just that reason. :)
Adapting the code to VB6 (which needs a different series of DLLs installed on the target machine) or to VBScript will likely be quickest.
Yes, VB.Net does require the .Net Framework. However, Windows XP is getting pretty old now, and recently dropped below a 25% installed base on some indexes. Windows 7 ships with .Net 2.0 out of the box, and Windows 7 sp1 also has .Net 3.5 at least available on the machine.
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.