This question already has answers here:
Mocking framework in UWP Apps [closed]
(2 answers)
Closed 6 years ago.
I'm creating a library for Universal Windows Platform apps ("Microsoft.NETCore.UniversalWindowsPlatform": "5.0.0" under dependencies and "uap10.0": {} under frameworks in project.json). I just started writing tests, but I can't seem to find any mocking library which would support the Universal Windows Platform apps. The only one is MoqaLate, but it's very new and severely limited.
I can't see myself testing without mocks, but I'm also new to UWP development. Am I missing something, or it really is impossible to use mocks in my tests? If so, what are alternatives?
Edit: One alternative I see is to develop Windows Class Library (Portable) which would target only Windows Universal 10.0. Is there any gotcha with this approach I should be careful about? My goal is to have a library that can be used in Windows 10 apps (on mobile, desktop and xbox).
Windows 10 uses .NET native to compile release builds down to machine code, so you are no longer working with MSIL and therefore the techniques used by mocking frameworks (IL weaving etc) cannot be used.
However, in debug mode your Windows 10 app runs standard .NET IL (for faster build / debugging cycles) so any mocking framework should work in debug mode as long as you only use it in a PCL project.
Related
I have experimented with XAML UI programming using C++ for Windows 8 Store apps. I really like the developer experience, the XAML designer and the fact that I can get pure native apps with a modern rich user interface and high performance.
I want to create similar XAML apps using C++ for Desktop Windows (the non-Store world). How do I do this? For years I have waited for a native UI stack for Windows Desktop which is newer than MFC and somewhat higher level than direct Win32/GDI programming.
Both Silverlight and WPF use XAML along with code-behind to implement apps. Neither are still maintained but if you want to play with the same technology, it's there.
As Jeff McClintock mentioned, Microsoft has announced that a future update to Windows 8 will allow apps to run on the desktop, but I expect that this will merely be a windowing change and the apps will still run in the restricted sandbox that Store Apps run within. Maybe Microsoft will introduce yet another desktop-based UI framework and support it for three years before killing it.
WTL is newer than MFC, although its last update was six years ago. I personally recommend Qt, as it allows access to native Win32 calls (so you can do whatever ganky stuff Win32 apps normally want to do) while still having a rich, robust UI framework to build upon.
A future update to Windows 8.1 will allow Windows 8 Store Apps to run in a Window on the Desktop, and appear on the taskbar like a Win32 Application. This allows Store apps to Act a lot like Desktop Apps. MS have hinted store-app XMAL will be available to Desktop apps at some point in future.
http://www.gottabemobile.com/2014/04/02/microsoft-listens-to-users-start-menu-and-windowed-apps-are-on-the-way/
Codejock has some markup language support in MFC (native C++).
http://www.codejock.com/inc/img/downloads/samples/toolkitpro_markupsample_full.png
What I am looking at is C++/WinRT for native C++ applications that use the WinRT framework for UWP apps, at least for Windows 10. See C++/WinRT in the Microsoft Dev Center for a starting place.
C++/WinRT is an entirely standard modern C++17 language projection for
Windows Runtime (WinRT) APIs, implemented as a header-file-based
library, and designed to provide you with first-class access to the
modern Windows API. With C++/WinRT, you can author and consume Windows
Runtime APIs using any standards-compliant C++17 compiler. The Windows
SDK includes C++/WinRT; it was introduced in version 10.0.17134.0
(Windows 10, version 1803).
The intro article in the series goes on to say:
For authoring and consuming Windows Runtime APIs using C++, there is
C++/WinRT. This is Microsoft's recommended replacement for the Windows
Runtime C++ Template Library (WRL) and C++/CX.
I first got started with UWP apps for Windows 10 using C++/CX which uses the Microsoft Visual Studio C++ extensions with ref and all of the C# like extensions for C++ in a .NET world.
I am now working with Visual Studio 2017 and the C++/WinRT framework which uses native C++17 features along with an SDK. I believe you can also use C++/WinRT with Visual Studio 2015 with the latest updates, update 3.
There is also a package available from Extensions and Updates within Visual Studio, C++/WinRT, which contains a couple of Visual Studio templates for a couple of different application types.
C++/WinRT seems to be a work in progress. It seems best if you are using Visual Studio 2017 with the latest Windows 10, Version 1803, which contains the SDK and the XAML editor works fine. I have had problems with the XAML editor with an earlier build of Windows 10 Enterprise at work (IT Services maintains its own update servers and is a couple of builds behind the bleeding edge).
See also my question synchronizing SDK with Windows 10 update and using WinRT with Standard C++ which has an updated version of a test program from this article, C++ - Introducing C++/WinRT.
I have an executable I made using a CLI console application with Visual Basic 2010. I can run the program completely fine from my developer machine.
However, when I copy the executable over to another machine, re-boot to a pre-installation environment and run the executable again, nothing happens at all. There are no errors shown or anything.
My guess is the executable can't run without certain dependencies that aren't loaded at this environment, but I need it to work in a PE.
Any ideas on whats going on?
First of all, since the question is tagged "c++" and you mention C++/CLI several times, I assume that "Visual Basic 2010" is a typo for "Visual Studio 2010". But either way, whether you've written the application in Visual Basic (VB.NET) or C++/CLI, the problem is exactly the same.
My guess is the executable can't run without certain dependencies that aren't loaded at this environment, but I need it to work in a PE.
That's exactly correct. You've written an application that targets the .NET Framework. Somewhat like Java applications requiring a JVM, .NET applications require that the .NET Framework be installed in order to run (or a compatible alternative implementation, like Mono). Unfortunately, Windows PE does not support the .NET Framework.
Note that it is irrelevant whether you've written a WinForms, WPF, or Console application. Although they present their UI in very different ways, they all depend on the .NET Framework being installed.
You will need to (re-)write the application in a different programming language, one that generates native code without any dependencies on the .NET Framework. C and C++ are popular choices. If you choose to use C++, make sure that you create what Visual Studio calls a "Win32" project. This is one that targets the underlying operating system APIs directly (i.e. a native application) and does not have a dependency on the .NET Framework. Stay away from anything that has ".NET" or "CLR" in its description.
I don't really have a full comprehension of when an application is using .NET or not... I am just used to Linux C/C++ development. I hate Microsoft shit
It uses .NET whenever you use the .NET Framework libraries/classes in your code. I'm not really sure why this is so difficult to understand. The same problem could easily exist on Linux if you were using a third-party library that was not available in certain environments for whatever reason. This is not Microsoft's problem, it's an issue of using the wrong tools for the job. The .NET Framework is an object-oriented wrapper around the native APIs that makes it much easier for people to get up and running writing programs for Windows. But if you're "used to Linux C/C++ development", you should have little trouble writing a simple console application that targets the native APIs directly without using .NET.
If your hatred for "Microsoft shit" has turned into an allergy, you can avoid Visual Studio entirely and download MinGW, which is a Windows port of the GCC compiler you're probably used to. Combined with your favorite Windows port of Vi, you're working in an environment very similar to the one you're used to. And since GCC doesn't support C++/CLI or the .NET Framework, you won't have to worry about getting stuck picking the wrong option.
The .Net framework has been supported as an optional package install during your PE build process for the past couple versions of WinPE. I write code in C# that I run in WinPE everyday. I have yet to find a good way to debug in a manner where I can walk through break points, etc... though. My best option has just been a lot of logging and a global Exception catch around my main entry point that will write out a full stack dump. You can attach to your app as a remote process in a VM running WinPE, but if you need to catch something early in the execution you'll have a difficult time.
I know that the recommended language for Windows Phone 7 development is C#.
However, for various reasons, I very much prefer continuing to program in standard C++, if possible.
Is it possible to program for Windows Phone 7 in standard C++ only?
If the answer is yes, what tools and resources do I need to accomplish that?
EDIT, finally: for WP7 it won't ever be, but for Windows Phone 8 - yes you can. Native apps, C/C++, iOS/Android portability and code sharing, DirectX. You'll need Visual Studio 2012 and Windows 8 for WP8 development, though. VS2010 is not getting the requisite SDK. To run the emulator, you'll need a 64-bit physical Windows 8 box with a SLAT-enabled CPU. You can still develop on a virtual machine, but you'd need a device to run apps, the emulator won't start.
The nongame UI, however, will still be XAML-based and managed. The entirety of Win32 API will not be supported. They're pushing a model with managed UI layer and a native middleware beneath it. Purely native development is still not an option; although one might try with WinMD classes as code-behind for XAML. The visual XAML designer will probably choke, and you'll need a dummy managed DLL anyway.
EDIT: even assembly, as long as it's targeting Thumb-2 and the mnemonics are UAL-style. For running on the simulator, you'd have to produce an alternative set of assembly files (or other sources) targeting Intel.
For the sake of posterity, here's the pre-06/20/2012 answer:
If you work for Microsoft or an OEM, then yes. Otherwise, no (for now).
There's hope though. Google did relent and issued their NDK after a while; Microsoft might, too. The native code capability is already there. Once they come up with a sensible sandboxing solution, why not.
Also, there's already some pressure from big-name software vendors to open up native development. Mozilla people stated outright that there will be no Firefox on WP7 unless it's native. Similar rumors about Flash.
EDIT: if you want a native SDK on WP7, like I do, please go sign the petition here and/or the one over there. Thank you!
EDIT2: see this. It's a leak and therefore not official, but still, I say there's some hope.
EDIT3: also this. Still not official, but this rumor moves the timeframe for native app support even closer - to the upcoming Tango release.
EDIT4: Microsoft seems to be pretty keen to promote WinRT, their new tablet-oriented XAML-based app platform, which allows for (among other things) unmanaged C++. Now, on every other major mobile OS the tablet and the phone app stacks are one and the same. Just sayin'.
EDIT5: there's been some proof-of-concept work along the lines of C++ => LLVM => MSIL and C++ => LLVM => C#, but nothing production-quality so far.
Phone manufacturers such as Samsung can deploy applications written in unmanaged code, but all other developers can not.
No that is not possible. Microsoft has made a decision to only allow application developers to use managed code on the Windows Phone 7 devices.
According to Wikipedia Windows Phone 7.0 runs Windows CE 6.0 R3/7.0 hybrid as operating system.
In theory one could use C++ to build standard* C++ programs targeting Windows CE 6.0 R3 and 7.0 (supposed to come out on Q1 2011). I mean all the standard* dlls should be there (gdi32.dll, user32.dll) Internet Explorer and other C++ programs are still running on Windows Phone 7.
The how to get the application on the phone? and how to run the application on the phone? are the next questions which at the moment I don't know how to answer.
This interview tells something about it: Writing the WP7 App Platform in C# and C++ I haven't watched it yet, so you might add respective comments :)
Windows Phone 7 supports Silverlight and XNA.
All programs for Windows Phone 7 are written in .NET managed code. It is also possible to write Windows Phone 7 applications in Visual Basic .NET.
Visual Studio 2010 Express for Windows Phone includes XNA Game Studio 4.0 and an on-screen phone emulator, and also integrates with Visual Studio 2010. You can develop visuals and animations for Silverlight applications using Microsoft Expression Blend.
The Silverlight and XNA platforms for Windows Phone 7 share some libraries, and you can use some XNA libraries in a Silverlight program and vice versa.
But you can’t create a program that mixes visuals from both platforms. Maybe that will be possible in the future, but not now.
EDIT:
to be more clear..there is no native C++ support you'll have to use either Silverlight or XNA,both are based on .net framework.
Native exe!
that means my program can run easily without any requirement?
even if I use .net classes?
You know I want to write a program that is so light and I don't like to use C# or any other .net programing language because all of them need .net-framework 4.5.
Just think a 2.5 MB programm needs a +250 MB .netframework.
New Update - 12/01/2016:
It's almost 4 years ago when I asked this question. As you know Dotnet Native is announced. It's an interesting feature which compile IL into native code.
Compiling Apps with .NET Native
.NET Native is a precompilation technology for building and deploying
Windows apps that is included with Visual Studio 2015. It
automatically compiles the release version of apps that are written in
managed code (C# or Visual Basic) and that target the .NET Framework
and Windows 10 to native code. Typically, apps that target the .NET
Framework are compiled to intermediate language (IL). At run time, the
just-in-time (JIT) compiler translates the IL to native code. In
contrast, .NET Native compiles Windows apps directly to native code.
For developers, this means:
Your apps will provide the superior performance of native code.
You can continue to program in C# or Visual Basic.
You can continue to take advantage of the resources provided by the .NET Framework, including its class library, automatic memory
management and garbage collection, and exception handling.
Last I checked none of the .NET frameworks were 250+ MB! Yes, the offline installer for .NET Framework 3.5 SP1 is 231MB but it contains x86 and x64 versions of .NET 2, 3 and 3.5 sp1.
You should read this http://www.smallestdotnet.com for details on sizes of various versions of the installers.
Now on to your question:
Yes, It is a little annoying to have your clients install a big framework, even 20-40MB does get annoying. With .NET, the advantage is the ease of programming (In my opionion) compared to other Native options.
Your native options are:
MFC - You need only the VS runtimes installed, which is 1-2MB and is usually installed on newer pcs. Also, you can ship your application with the MFC libraries packaged into a dll which is again <2MB
The trade of here is you need to program in C++, the libraries overall are a very thin layer over the native libraries. and people have had harsh opinions about MFC. I've barely just tried it.
Win32 API - This is going all bare bones, and quite difficult, you could use C or C++ but you'd really have to know a lot about the Win32 API and how windows itself works (Stuff like windows messages, hwnds etc) Its not fun, believe me. But during deployment you would not need any external libraries.
There are tons more options, see here:
Native Windows Application Development Options
https://stackoverflow.com/questions/2711599/what-programming-language-should-i-use-to-create-small-native-windows-applicatio
Here are some links on MFC that might help:
Want to learn Windows Programming,some suggestions?
How do I decide whether to use ATL, MFC, Win32 or CLR for a new C++ project?
C++ MFC vs .NET?
https://stackoverflow.com/questions/557114/stick-with-mfc-or-go-to-net
you are able to create native exe by using c++ Win 32 projects.
Alas, nearly everything requires a download runtime library and even if you have one installed, you'll need to download updates for them almost continually. Even Microsoft C++ apps nowadays come with security updates that have to be installed if you've compiled your app with them.
But.. there is a solution of sorts. If you use C++, it has a feature where only the things you use are compiled into the final app. Normally, this would require linking with all the library dlls, but if you statically link with the library, you will end up with a single .exe that is as small as can be, and you will not need any dlls (as all the code contained in the library will be compiled into the .exe).
The benefits are debatable compared to dlls, but as MS has pretty much broken the idea of shared dlls in .NET (ie, you practically have to put all the shared dlls in the same directory as your running app, giving you a nightmare in maintenance if you have these shared dlls spread around all your apps) then there's not much of a difference anymore. Static linking is getting a little bit of a comeback and sounds like its what you want.
For modern C++ development, you'll probably want to take a look at Qt instead of MFC. Its a lot nicer to use and is cross-platform so you can run Qt apps on your Android or Linux platforms as well as Windows.
I need to give an estimate for porting a standalone program to a Mac from a .NET platform. I have all the source code which is in C++ and is both code I wrote and a modified version of GLUT/GLUI because the program uses OpenGL and GLUT/GLUI as a UI.
I don't think the C++ code will be a problem or the OpenGL environment, please tell me if you think it will be. In .NET, I use OpenGL32.DLL and deploy it with my app. I need to find out how this is done for a Mac?
I really need to know what the current deployment method is for Mac's these days and how hard it will be for me to write for it. For .NET, I use Visual Studio for the application development and deployment, I make a new VS project to build the deployable MS installer.
The deployment process also allows things like placing a desktop shortcut, associate a unique icon with the program ... What deployment options can one select on a Mac? What do you think the biggest obstacles will be?
There's no .NET framework calls within the code. The deployment phase produces a .NET assembly with all the security features. I think that is the main relationship with .NET since it is straight C++ not C#.
Development should be rather straight-forward. You'll be able to do OpenGL/GLUT/etc... through the Cocoa framework. Look at this example from Apple to see how it is done in code.
As for development tools, you will be able to use Xcode (which is free with the Mac). You can develop in C++ and compile with GCC.