This is probably a bit crazy/nuts, but is there any way to perform WPF Automation Testing without using the MS Automation Peer framework?
There are several times when I actually need the UIElement/FrameworkElement and would like to access that directly. I was looking into Snoop to try and deal with it, but it looked like it was a bit painful to "inject" into a process.
I've tried connecting to the process that is launched (we're currently using SpecFlow), but any attempt to marshall the Process or Window thread (I've looked for the actual Window's proc ID and tried connecting) results in a null from the HwndSource. I was trying to also create an instance of the Application inside my unit test, but it looks like NUnit has issues with launching the Application in the background (even on a STA Thread), because the second a test starts trying to load, the Application starts blocking.
Has anyone had any success in doing something else? My only thoughts to "solve" the problem now would be to create a special AutomationPeer that I could reflect to and then get the FrameworkElement from, or something like that.
Any thoughts?
No, there's nothing that can marshal WPF elements (especially underlying native elements such as graphic resources, images, etc.) across processes, and UI Automation works by definition across processes.
If you own the target application, you can dramatically increase its "UIAutomation-ness" if you create AutomationPeers specific for your app.
Otherwise, the snoop way (process injection) is the only way (but has a lot of drawbacks, including security issues).
If this is the case:
any way to perform WPF Automation Testing without using the MS Automation Peer framework?
you can use the Telerik's Testing Studio, it's rich and with some coding you'll get use to it. Another plus is the good documentation and the help that can be provided by them.
To be honest it took me a while, but since the Framework is free I finally decide to use it over the MS alternative.
Related
I've been working on an internal developer tool on and off for a few weeks now, but I'm running into an ugly stumbling block I haven't managed to find a good solution for. I'm hoping someone can offer some ideas or guidance on the best ways to use the existing frameworks in .NET.
Background: the purpose of this tool is to load multiple different types of log files (Windows Event Log, IIS, SQL trace, etc.) to the same database table so they can be sorted and examined together. My personal goal is to make the entire thing streamlined so that we only make a single pass and do not cache the entire log either in memory or to disk. This is important when log files reach hundreds of MB or into the GB range. Fast performance is good, but slow and unobtrusive (allowing you to work on something else in the meantime) is better than running faster but monopolizing the system in the process, so I've focused on minimizing RAM and disk usage.
I've iterated through a few different designs so far trying to boil it down to something simple. I want the core of the log parser--the part that has to interact with any outside library or file to actually read the data--to be as simple as possible and conform to a standard interface, so that adding support for a new format is as easy as possible. Currently, the parse method returns an IEnumerable<Item> where Item is a custom struct, and I use yield return to minimize the amount of buffering.
However, we quickly run into some ugly constraints: the libraries provided (generally by Microsoft) to process these file formats. The biggest and ugliest problem: one of these libraries only works in 64-bit. Another one (Microsoft.SqlServer.Management.Trace TraceFile for SSMS logs) only works in 32-bit. As we all know, you can't mix and match 32- and 64-bit code. Since the entire point of this exercise is to have one utility that can handle any format, we need to have a separate child process (which in this case is handling the 32-bit-only portion).
The end result is that I need the 64-bit main process to start up a 32-bit child, provide it with the information needed to parse the log file, and stream the data back in some way that doesn't require buffering the entire contents to memory or disk. At first I tried using stdout, but that fell apart with any significant amount of data. I've tried using WCF, but it's really not designed to handle the "service" being a child of the "client", and it's difficult to get them synchronized backwards from how they want to work, plus I don't know if I can actually make them stream data correctly. I don't want to use a mechanism that opens up unsecured network ports or that could accidentally crosstalk if someone runs more than one instance (I want that scenario to work normally--each 64-bit main process would spawn and run its own child). Ideally, I want the core of the parser running in the 32-bit child to look the same as the core of a parser running in the 64-bit parent, but I don't know if it's even possible to continue using yield return, even with some wrapper in place to help manage the IPC. Is there any existing framework in .NET that makes this relatively easy?
WCF does have a P2P mode however if all your processes are local machine you are better off with IPC such as named pipes due to the latter running in Kernel Mode and does not have the messaging overhead of the former.
Failing that you could try COM which should not have a problem talking between 32 and 64 bit processes. - Tell me more
In case anyone stumbles across this, I'll post the solution that we eventually settled on. The key was to redefine the inter-process WCF service interface to be different from the intra-process IEnumerable interface. Instead of attempting to yield return across process boundaries, we stuck a proxy layer in between that uses an enumerator, so we can call a "give me an item" method over and over again. It's likely this has more performance overhead than a true streaming solution, since there's a method call for every item, but it does seem to get the job done, and it doesn't leak or consume memory.
We did follow Micky's suggestion of using named pipes, but still within WCF. We're also using named semaphores to coordinate the two processes, so we don't attempt to make service calls until the "child service" has finished starting up.
We are looking to write automated tests using coded ui test framework. We are looking to test the ui components in isolation without launching the application in a separate process.
For example if we have a pop-up dialog in the application to capture data from user, we would like to launch only the specific dialog and validate different use cases rather than running the whole application.
We tried to test by launching the dialog as part of the test initialize() but it is not able to find the controls... but the same test works fine if I launch the dialog separately.
Have anyone tried this or have advise to get this working ?
Coded UI Framework is a very powerfull framework yet has lots (and I mean LOTS) of problems.
I wouldn't recommend it to do what you are trying to accomplish.
Besides, testing "components in isolation" is unit testing, and from my experience this is not a best practice for Coded UI Test at all.
Coded UI test will help you in testing cross-application processes from end to end, closest to the user as it gets since its simulating the users inputs though keystrokes and mouse clicks.
Also, as UI tends to change quite a lot during development, and Coded UI relies on that, I suggest you use it mainly for regression testing for windows you know that are not going to change anytime soon.
This way you'll keep you maintainance low and productivity high.
Hope this helps.
Coded UI is intended for checking the functionality of applications (and also of web pages). Coded UI is not for testing fragments of UI separate from their application. However, it would be possible to create a test harness application that contained one or more UI components allowing them to be tested in isolation from the real application.
A test harness could easily have a window for each component being tested. The window would include the component being tested plus a some other simple controls. These simple controls could expose internal values of the component being tested and also be used to pass values into the component.
I think what your attempting to do is viable, however ONLY for your own custom controls. I think you should tackle this in this order.
A second instance of VS to capture what it actually sees about your control when your test spawns your control.
Update your search criteria, e.g. process name, window title
Potentially add properties to your TestInitialize spawner so it creates your control with useful ID's, names, or titles. (not sure which tech stack your control is in)
Run tests again
I've got a for loop I want to parallelize with something like PLINQ's Parallel.ForEach().
The key here is that the C++ library i'm calling to do the computation is decidedly not thread safe, therefore, any plans to parallelize this need to do so across multiple processes.
I was thinking about using WCF to create a "distributor" process to which the "client" and multiple "calculators" could both connect and add/remove items to/from a queue and then the "calculator" sends the results directly back to the client which could update the gui as it receives them. This architecture would allow me to bring as many "calculators" online as I have processors and as I see it even bring them up across multiple computers creating a potential farm of processing power to which all the clients could share.
I'm just wondering if anyone has had any experience doing this and if there are existing application blocks or frameworks that I can use to build this for me. PLINQ does it within the process. is there like a DPLINQ (distributed) or something?
Also if that doesn't exist, does anybody want to give an opinion on my proposed architecture? Any obvious pitfalls? Does anyone think it will work!?!?!?
Sounds like you could be looking for Dryad. It's a Microsoft research project right now, but they do have an "academic release" available. My understanding is that they are also in the process of better productizing it (probably some kind of integration with Azure) for RTM sometime near the end of 2011. Mary Jo Foley covers more about this here.
A long time standard for controlling/dispatching distributed work is MPI. I've only ever used it from C++, but implementations from many languages exist. A quick google suggests that MPI.Net could be a good implementation for .Net!
Playing around with project ideas that I might actually use, figured I might try to write my own simple version of Bit9 Parity, in either C# or Python. My question is what is the best way to go about doing this. I've googled .Net functionality for prevent processes from executing, but I havn't really found what I'm looking for. What I'd like to do is monitory the system memory as a whole, and deny any process or application from starting unless specifically identified in a list. ProcessWatcher caught my eye, but is that not for a specific process ID. How do I block ALL other processes from starting? Is this possible in .Net? What about python?
This blog post (Using WMI to monitor process creation, deletion and modification in .NET) shows how to do that. With a few changes, you should be able to do exactly what you want.
How do I block ALL other processes from starting?
Deep, mysterious OS API magic. After all, you're interfering with how the OS works. You must, therefore patch or hook into the OS itself.
Is this possible in .Net? What about python?
It doesn't involve time-travel, anti-gravity or perpetual motion. It can be done.
It's a matter of figuring out (1) which OS API calls are required to put your new hook into the OS, and (2) implementing a call from the OS to your code.
Is really hard.
Is really easy.
Is there any way to hide a C# program from the Windows Task Manager?
EDIT:
Thanks for the overwhelming response! Well I didn't intend to do something spooky. Just wanted to win a bet with my friend that I can do it without him noticing. And I'm not a geek myself to be able to write a rootkit, as someone suggested though I'd love to know how to do it.
Not that I'm aware of - and there shouldn't be. The point of the task manager is to allow users to examine processes etc.
If the user should be able to do that, they should be able to find your program. If they shouldn't be poking around in Task Manager, group policy should prevent that - not your program.
Don't mean to zombie this but i thought i could contribute some useful information
If you want to hide a application there a two methods (that i can think of atm).
They both have their ups and downs
[1] SSDT Table hooking - basically you have to set the MDL of the table to writeable, overwrite the address of NtQuerySystemInformation (iirc) with the address of your function and have it call the original function after filtering the results.
This method doesn't suit your needs very well because the hooking function would always need to be in memory and would involve writing a kernel mode driver. Its a fun thing to do but debugging is a pain because an exception means a BSOD.
[2] Direct Kernel Object Manipulation (DKOM) - the list of processes is a doubly linked list, with a kernel mode driver you can alter the pointers of the records above and below your process to point around yours. This still requires the use of a kernel mode driver but there are rootkits such as FU that can be easily downloaded that contain an exe and the service. The exe could be called from inside your application as a child process (in the released version of FU, at least the one I found, there was a bug which I had to fix where if the hidden application exited the computer would BSOD, it was a trivial fix).
This will thankfully be caught by almost any decent antivirus so if you are trying to do something sneaky you'll have to learn to get around that (hint: they use a binary signature)
I have not used method 1 ever but method 2 has worked for me from a VB.Net application.
A third possible option is to just create the application as a windows service, this will show up in task manager by default but I'm willing to bet that there is a way to tell it to not show up there since there are plenty of other services which don't show up in task manager.
Hope I helped a little, my advice is that if you are interested in this kind of stuff to learn C++.
You could make your program a service and then it would appear as "svchost". There's a little more to it than that, but that should give you a hint to go in the right direction.
I'm not aware of any way to hide it from the task manager, but you could just disguise it by making it show up as "svchost.exe". It'll get lumped in with all the others (there's usually several), and will become indistinguishable.
You shouldn't hide it, but you could prevent the user from killing the process.
See Chris Smith's answer to this question.