What is the difference between native only, managed only, script only and mixed (managed and native) debugger types? They can be found in a project's properties page.
Different runtime environments have different debuggers. You are giving the choice of debugger you want to use to avoid starting one up that you'll never use and thus cutting the overhead. The debugger types are:
Managed: suitable for .NET code written in a managed language like C# or VB.NET
Native: suitable for code generated by the C or C++ compiler
Mixed: a choice you'll make when you need to debug .NET code that inter-operates with native code, common in C++/CLI projects or when you need to debug a pinvoke problem
Script: useful to debug scripting code, like Javascript, that runs in a browser
GPU: used to debug C++ AMP code that runs in a graphics card
Silverlight: used to debug Silverlight code that runs in a browser
T-SQL: used to debug stored procedures that run on SQL Server
Workflow: used to debug WF workflows
Related
I'm in the process of writing some new C++/WinRT based components in order to replace some much older C++/CX code. The goal is to be able to use third-party C++ tools that don't understand CX (static code analyzers, etc).
However the first step in the journey is to ensure I can properly unit test my own code. Unit testing C++/CX code typically used the "C++ Unit Test App" project type, which is C++/CX based and has its own issues (lack of code coverage support, run all required before tests show up in the explorer, stability, etc)
Browsing through the available project types in Visual Studio 2017, I did not see a unit test project template for C++/WinRT based projects. Is my only option to use the "C++ Unit Test App" template with all its failings, or is there another way to build tests for a C++/WinRT library?
Perhaps there is a way to configure either the "Native Unit Test Project" or "Google Test" project templates to support what I'm looking for?
Ideally what I'm looking for is something that doesn't require launching a UI, is pure C++(/WinRT), and supports Visual Studio's Code Coverage Analysis.
There is no unit test project that is specific to C++/WinRT, much like there isn't one for other libraries like STL. I would recommend Catch2 as it supports C++17 (a requirement for C++/WinRT) and works well on Windows. It is also what we use for testing C++/WinRT itself. Catch2 is nice because it helps you create a simple console app that acts as the test driver that includes all of the tests.
For code coverage I don't have a strong recommendation, but if you are using Visual Studio then you might want to try VSInstr. It can be used for code coverage and produces a report that can be viewed with Visual Studio.
Make sure your code is built using the /profile linker option. This will ensure that profile hooks are included in a dedicated section of the PE file. Next, run vsinstr to instrument any of the binaries you're interested in (that were previously built with /profile):
vsinstr /coverage tests.exe
Now run vsperfcmd to begin collecting coverage data:
vsperfcmd /start:coverage /output:report
Run the code as normal. For Catch2, you can simply run the executable at the command line. Then you need to stop the collection as follows:
vsperfcmd /shutdown
And you're done. You can now view the report in Visual Studio:
devenv report.coverage
Hope that helps. Again, this is not specific to C++/WinRT and since C++/WinRT is a header-only library you are liable to get a lot of noise that is unrelated to your specific project. I haven't found a good way to deal with that yet.
Expanding on my comment to #KennyKerr's answer for those that are interested...
If you are planning on using Catch2 as recommended, then the C++/WinRT Windows Console Application template is a great starting point. Pretty much all you have to do is tweak the main() to setup Catch2 and start writing your test cases. My only complaint is that the C++/WinRT templates don't allow you to add Windows Runtime Component project references via the UI (must be done by editing the vcxproj). There is probably a similar problem adding NuGet package references.
As noted in my comment above, there is a Catch2 test adapter for Visual Studio 2017/2019 in the marketplace. Be aware that it requires a .runsettings file to enable the adapter and to tell it which projects are Catch2 test applications (via a regex). Without a properly configured runsettings, it will not find your tests. I also had to increase the discovery timeout, otherwise it "forgot" my tests occasionally.
With regards the code coverage, when using Visual Studio you can configure the code coverage to include/exclude functions in the .runsettings file. See Microsoft's Site for details. For myself I added the following in the CodeCoverage section and it works pretty well so far:
<Functions>
<Include>
<Function>.*YourNamespaceHere.*</Function>
</Include>
<Exclude>
<Function>winrt.*GetRuntimeClassName</Function>
<Function>winrt::impl.*</Function>
<Function>winrt::(?!YourNamespaceHere).*</Function>
</Exclude>
</Functions>
For those that are trying to test a C++/WinRT Windows Runtime Component like me, and have code that is not exposed as part of the WRC interface, here is what I did to make that testable...
Create a C++ Shared Items Project
Move all of the code for your Windows Runtime Component (WRC) project into the shared items project, and out of the WRC project. Going forward, only add/remove files from the shared project. That way you don't have to touch the WRC or Test projects when files are added/removed.
Add a reference to this shared items project in both your original WRC project, and your test project
Make sure your test project and WRC project are configured similarly with respect compile settings and project/NuGet references
Edit the test project and ensure the RootNamespace is configured the same as the WRC project (probably has to be done via your favorite editor). This is required otherwise the generated headers will be prefixed with the namespace, and thus won't be found by the shared code.
(Optional for Code Coverage) In the test project, enable profiling (Linker > Advanced > Profile > Yes)
You should now be able to write tests that exercise the private code. As to whether or not this is the best approach, I leave to the reader. It works for me, and the code I'm testing is simple enough that I'm not overly concerned with the project definitions not aligning perfectly. Your mileage may vary.
I will note that the above can also be used to make the "Native Unit Test Project" work with C++/WinRT, you just have the extra steps of integrating the C++/WinRT bits into the test project first.
I am currently doing some research on techniques about hooking mobile applications and came across some frameworks like Xposed (Android), Frida (Android and iOS) and Cycript (iOS).
The documentation about Xposed and Frida is fairly good explaining how exactly they are doing it. Xposed states to manipulate the binary starting the Zygote process and loading an additional JAR file that assists in hooking the methods. Frida documentation explains that it uses ptrace (in Linux environments) to attach to a process, allocating and populating a bootstrapper that loads a thread to launch a .so file containing the frida agent, in a nutshell, if I understood it correctly.
I couldn't find useful documentation about the strategy that Cycript pursues. I know that it is built on top of Cydia Substrate that does the actual hooking. I couldn't find details about how exactly Substrate accomplishes this either.
I further understand that on iOS the objective-c runtime enables runtime manipulation as it is runtime-oriented.
Does anybody know how exactly Cycript / Cydia Substrate works to hook/inject into applications?
Thanks in advance.
It figured out that is apparently working by adding the DYLD_INSERT_LIBRARIES into the program's launchd manifest and thereby every time the application is started it loads the malicious payload by loading the dynamic library.
Still, are there other techniques how to perform runtime hooking / manipulations on Android and iOS?
Can you use the InternalsVisibleTo assembly attribute in a AssemblyInfo file of a MonoTouch Library to allow MonoTouch Unit Test (Touch.Unit) access to the internals of the MonoTouch library?
This is something that is great to use in non-MonoTouch world to allow testing of internals without having to jump through hoops. However I am not able to get it working with a MonoTouch Unit Test. So before I go any futher I figured I would ask if it is even possible, since this is an iOS Application that is the test runner, so not sure if an iOS application which is compiled to native code can even do this.
Yes, it should (or it's a bug) even if I do not recall trying it myself.
The key point is that [InternalsVisibleTo] is mostly a compiler trick and it is supported by the C# compiler (smcs) shipped with MonoTouch (as it's used inside the BCL). As such there's no reason why it should not work from a Touch.Unit-based application.
Now keep in mind that all other rules still applies. E.g. if the the managed linker is enabled when all unused code will be removed (even if marked with the attribute).
Due to MonoTouch using dll's within the actual app, how secure is this approach? For instance, if someone is using the Mono.Security.dll, couldn't someone swap out that dll with one which implemented the methods and perform a code injection attack on an app?
how secure is this approach?
As much as any existing ones I know :-)
couldn't someone swap out that dll
No for several reasons.
You cannot change the applications files. That would break the digital signature and iOS won't execute it. That alone removes a MitM attack;
the code from every .dll is already compiled to native code (by the AOT compiler) and part of the main executable binary. Swapping a new .dll won't change the code that is executed;
the .dll that is deployed on devices is stripped (for release builds). There's no IL (code) inside it since it would not be useful (we can't JIT on iOS). Even if you add a .dll with IL code (e.g. a debug build) it won't be executed (again it would require JITting);
Why are the .dll deployed ? for their metadata (e.g. if you use reflection)
Final note: MonoTouch produce native ARM executables just like Objective-C would.
I've picked up a legacy application developed in C/C++ on Linux, using ncurses for UI. What automated testing tools are there for this environment?
Edit: I've used AutomatedQA TestComplete in the past, and this is the type of tool I'm looking for - except running on Linux, and with the ability to test Text UI apps.
I wrote something like that before. Not much docs, but you can try the code. It's written in Python and runs on Linux.
You would basically need the ANSIterm filter, and the expect module. Then you compose them into a filter. You'll likely have to start the process with the proctools module. They are all designed to work together or separately (modular).
I have considered using Rational Function Tester and TestComplete.
RFT has explicit support for testing this type of application (text-mode linux) via built-in terminal emulation.
TestComplete does not support testing Linux apps directly, but can be made to work by "testing" a COM-enabled terminal emulation program (Attachmate Reflection at this stage), and using COM from the test scripts to do screen scraping.
Have also considered using Reflection as the terminal emulator and rolling my own test framework in C# and NUnit.
Edit: "Final" solution is using Terminator (a Java terminal emulator), extending it with an RMI interface and using TestNG...
The expect tool sounds like what you need: http://linux.die.net/man/1/expect
Have a look at the free version of TETware from the Open Group. It is a full test harness based on TCL.