I am trying to develop a basic app in Visual Studio that does a simple video chat with another person. Everything was working fine and I was able to successfully open a video chat. However, I have installed Lync with UI Supression, and the app will not run. Examining the InnerException I can see that the program is throwing a COMException "Exception from HRESULT: 0x80C8000B"
Via process of elimination I have found that commenting out the line auto = LyncClient.getAutomation() lets the app run, though the functionality of the app is gone.
After all my searching online I cant determine what could be causing this line to break it, and I know I need that line of code in order to move forward.
Automation is not available to you when running in UI Suppression Mode.
Suppression mode requires that Lync be installed on the client's machine, but you then need to use the Lync SDK to do a lot of the things that the client does for you, such as signing in (no trivial matter). However, the Automation section of the SDK is the link to the standard Lync UI, which is why it is unavailable to you.
You also don't have access to any of the UI controls that make up the Lync client ... with the exception of the VideoWindow control - which will most probably be useful to you.
There's a good article on understanding UI Suppression Mode here: http://msdn.microsoft.com/en-us/library/hh345230.aspx
Also, a great sample of how to sign in to Lync when using UI Suppression Mode: http://msdn.microsoft.com/en-us/library/hh378603.aspx
One more thing: if you have access to it, in this book on Lync chapter 5 actually has an end-to-end example of producing a UI Suppression AV kiosk app in WPF - which might be exactly what you're looking for.
Related
Apologies, this may not be a good question.
I have a VB based UI application running, supported by C++ modules through COM.
a month before it started to close randomly without any clue. I initially analyzed in perspective of a application crash and expected to see Dumps and Application/System event log entries. I have prior experience in application crash debugging. tried registry configurations (Like, CorporarteWerServer for application hang, LocalDumps and all that).
But no luck.
End user says they don't see any popup like "This application is not responding with options close/wait". The application just closes down without any prompts.
We have logging enabled where we intentionally close the application using exit(). So it is not closing formally.
User does not have testing environment where we can install debugging tools and monitor.
I have verified for insufficient memory and antivirus software and they are fine.
So, Is there any cases where an application can just simply close/crash without any prompts, logs, dumps ?
Please suggest if I am missing something. Also, is there any built-in windows tools to monitor ?
At a client of mine, in-house applications are all located on a network share. Users create shortcuts to the required applications from the network share so we can easily make sure everyone uses the latest version.
This works fairly well, although we often have an issue when users are still using applications when we'd like to release a new version. For most applications, we'd forcibly remove all the file locks on the server and release the new version. Not a very elegant solution, especially since we need assistance from another department for this.
For newer applications, I've developed a cleaner solution, where the application intermittently checks if it's still the most recent release. If it isn't, it shows a message to the user, asking him to quit the application at first convenience, or within 3 minutes. After 3 minutes, the application quits itself and all is well. However, some users will immediately try to re-start the application. The application will then show a simple MessageBox telling the user this version is currently not supported. My problem is this: while this MessageBox is visible, my executable is still locked.
I'm looking for any of the following solutions:
Releasing all locks on the current assembly files from within code
Showing a message box that lingers after the current assembly has exited
This is exactly precisely the problem that .NET ClickOnce deployment is meant to solve. Users have a shortcut they can click, the latest version is downloaded on application start, and there are no server-side executables to be locked if a user leaves their process open.
ClickOnce Deployment Overview
HowTo:Publish a ClickOnce Application
I am doing some research into building a cross-platform desktop application using web technologies. Both node-webkit and electron/atom would be perfect for the job.
However, with it being a multi-window app, my clients aren't too keen on the vast number of processes which chromium creates (2 per window).
I've looked into passing some different command line switches, --single-process and a few others but they only seem to cause the app to crash on startup.
I then looked at node itself, the closest i got here was the process API exposes methods to set the group PID. Alas, this is unsupported on windows which is my primary target platform.
I don't know if you've ever googled "hide process from task manager", it's starting to look a bit scary and deep-webish. there must be an easier way.
Does anyone have some suggestions or maybe a different technology?
This isn't possible, sorry! The code that allows single-process in Chromium is busted and bitrotted
I've been dealing with the same issue and can confirm that as of Electron version 1.4.10 the --single-process flag is still crashing the app.
I ended up using --process-per-site. It groups the processes per web site/domain. If you are using Angular in your app (with the same index page), all Browsers will be launched with the same process.
https://www.chromium.org/developers/design-documents/process-models
I've downloaded and installed the windows 8 consumer preview, and I'd like to figure out how to use the UI Automation API's to get data from metro style applications.
Background: I have a lot of automated tests which use the Microsoft UI Automation API's to interact with applications. The scripts are written in IronRuby against .NET 4
Initially, I'd simply like to check if the start menu is visible (and if so, close it)
According to Microsoft, the normal UI Automation API's should be able to access and control metro style applications, but the problem is, I can't figure out how my code can actually access the UI of metro applications? Our normal way of viewing UI automation data is using UISpy, however when I run UI spy under windows 8 and bring up a metro app, there is no mention of it... it seems like metro apps (including the start screen) are walled off from the desktop.
If I can't find the metro apps in UISpy, how can I find what their automation ID's are, and how could I find them from my automated test scripts?
A few resources on UI automation which works in Metro style apps:
Here is a sample demonstrating it.
Here is a blog post explaining it.
This is a forum thread on the subject.
There is nothing about the app that stops traditional UI automation from working correctly. You may have to get updated tools to view the Metro style apps. Some ship with the Consumer Preview. Look for inspect.exe.
UI Automation tools can automate Metro applications. Check RIATest for example.
Stating from version 6.0 a number of features in RIATest are specifically targeted at Metro style application automation, particularly:
Ability to stay on top of Metro UI to allow you to simultaneously see your Metro application and RIATest IDE and minimize switching from Desktop to Metro screens when automating a Metro application.
Recording of actions performed on native Windows GUI elements (including Metro GUI). The recorder analyses your script code and reuses your variable names to generate cleaner recorded scripts similar to how you would hand-code an automation script.
Seamless workaround for bugs like this in Windows UI Automation implementation in Metro UI.
Disclaimer: I work for Cogitek, the RIATest company.
WinRT (aka "Metro Style") applications run in an sandbox. You cannot pierce the walls between applications, including to Desktop applications. This includes network isolation (you cannot refer back to localhost for example except in a development environment). There are a couple of exceptions to this such as the Share and Search contacts which allow for very specific types of interactions between apps.
It is this sandbox that is preventing UISpy from seeing the executing WinRT application in the background. I'm not sure how UISpy could work around this issue without some kind of development environment exception to the sandbox (similar to the network isolation exception) that isn't available in the consumer preview.
I'm also unaware of any announcements regarding when/if the UI Automation API will be supported for WinRT applications at this time.
With Visual stuido 2010, it's simple to set up SL4 to debug with an out-of-browser installed app. I followed the instructions from here and everything seems to set up fine. Debugging from the browser runs the program just fine, but running from the OOB program gives a different result. After starting, the screen will go blank and then hang forever. I have some concerns that it might be because of some of the technologies that we're using.
Firstly, there's a popup that happens because we're using WCF RIA Services (formerly .NET RIA Services).
"RIA Services will fail unless the silverlight project is hosted and launched from the same web project that contains the RIA Services."
This seems to just be a warning, but I have a suspicion that this warning might be telling me that RIA Services needs to have the .web project as its startup project.
We're also using prism and the error has an odor of a Prism error too. (something loading and then not ever appearing)
Has anyone else had any issues with OOB debugging in SL4? Is anyone else OOB debugging in SL4?
Sorry it's so vague. It's a complicated mess. The only message I see is the italicized popup warning. Then the window (which was previously showing the background of our application) just goes blank
There is currently a known issue with debugging an Out of Browser Silverlight 4 application when using F5 to launch the application from within VS 2010. The question I have is whether or not the application launches without debugging (-F5 or running it from the shortcut)? In the case of using F5, a dialog typically appears with the following error dialog “Unable to start debugging. A fatal error occured. For more details, please see the Microsoft Help and Support web site. HRESULT=0x80070018” and then the application appears to hang. In this case detaching allows the process to continue and then reattaching should allow you to debug the process.
If this is completely blocking or you’re trying to debug code running at startup (like the page startup event), one possible way to get around this would be to put in a call to System.Diagnostics.Debugger.Break, start the program and then attach when dialog pops.
This can be caused by the OOBA install being older than the version you are trying to debug. Remember, Silverlight OOBAs do not automatically update themselves to the latest version of the XAP file that may be available on the server. You have to update them yourself. If you get this error and you have included the auto-update logic in your app, just bounce out of VS, run the app so it auto-updates, then go back in and debug.
Alternately, you can uninstall the app and re-install it. That will ensure you are debugging against the latest VS build.
I ran into this same issue with VS 2008 and Silverlight 3. If I got it, I just jumped out and updated the app then re-ran it in VS and had full debugging.