I'm debugging my application which has drag-n-drop features in Visual Studio 2010. I have to run the IDE in privileged mode since some of my project required so.
My problem:
I can drag-drop when run the .exe file normally (run from Windows Explorer (WE)) but when debugging in VS2010 I cannot do drag-dropping between my app and WE.
I tried to open WE in privileged mode but still cannot debug either.
Do you have the same problem? If you do, do you have any work-around for it? Please share.
Another workaround is to run the debug binary from Windows Explorer and attach to the process from within Visual Studio via the "Tools" or "Debug" menu. I have verified that drag events are received in the debugger when using this approach.
This is by design, an aspect of UAC called UIPI (User Interface Privilege Isolation). It prevents a non-elevated process from hijacking an elevated one through Windows messages or drag and drop. It protects against shatter attacks. There is a way for the elevated process to explicitly allow messages with ChangeWindowMessageFilter. But not for drag and drop, it isn't message based.
There is no decent api-level workaround for this, it has to be done declaratively. The manifest for the program needs to use uiaccess = true, be code-signed with a certificate from an approved authority and be installed in c:\windows or c:\program files.
Related
I am developing an add-in for Word to add ribbon bar functions for our business.
I am developing the add-in in VB.Net using Windows Visual Studio 2017.
The machine is currently a stand-alone machine that is not connected to the main network.
My issue is that for some reason, the add-in seems to have set itself up in such a way that it appears to have already been installed on the system and loads, with the most updated code, if I just start Word normally.
Any development has been done in Debug mode and I have not been re-building the solution in release mode, and yet anything I change and then run/debug updates the code that the add-in appears to be run off when opening Word directly.
If I go through the options --> add-ins and disable the VTSO add-in it just gets enabled again. I don't seem to be able to separate a debug/development section and live code.
Edit from comments: I can accept that the VTSO needs to be installed and registered but having no separation of live code and development code is frustrating. This machine is used by others for other purposes and this includes using Word, and so any old code must be kept as comments that can set back as the working code should I need to leave part way through. I cannot leave anything partially written as any run the debug mode will set the code as live.
What you're experiencing is normal behavior. When you debug, VSTO registers the add-in in the Windows Registry. This is all that's required for the Office application to find and load the add-in when it starts.
If you disable the add-in in Word, it will remain disabled until you again debug the add-in in Visual Studio.
If you share the machine and want to have the add-in under development disabled for other users:
Work with separate user profiles. VSTO registers its add-ins under CurrentUser, not for all users - VSTO isn't designed to register add-ins for the entire machine. OR
Get into the habit of using Visual Studio's Build/Clean Solution functionality when you leave the machine. That unregisters the add-in (until it runs in debug mode again).
I created a Windows Store app using Visual Studio(2013). Right-clicked the project and chose "Deploy". Where was the app deployed? What I want to do is to be able to run that app from cmd, not from Visual Studio.
So the question is: where is the app deployed? Can I somehow change that location?
Normally installed Windows Store apps are found here: %programfiles%\WindowsApps\IdentifierForYourApp. But when you deploy from Visual Studio (for the purposes of debugging and whatnot), Visual Studio just registers the app to run from within your build output folder.
But I don't think you can launch the program from a command line. Even if you try to just double-click the executable, you get an error "This application can only run in the context of an app container"
You can launch the app via the IApplicationActivationManager::ActivateApplication function in C++ code. There might be another way via managed code, but I'm not aware of it.
"Unable to start debugging 'C:\Windows\System32\WWAHost.exe'. The Microsoft Visual Studio Remote Debugging Monitor (MSVSMON.EXE) does not appear to be running on the remote computer. This may be because a firewall is preventing communication to the remote computer. Please see Help for assistance on configuring remote debugging."
Searched for similar posts, but didn't found one. If duplicate just inform.
I am not trying to connect to any remote machine. Just testing on my local machine.
Is there any way to solve this issue. (I'm using Windows 8 Enterprise 64-bit, just a javascript project)
Problem solved. Installed Remote tools update from here and working fine. Thanks for responding. Closing the topic.
I had the same problem. I fixed it by changing properties/compile/target platform to x86 instead of Any CPU. It solved the problem in my case. Hope it helps.
This happened to me just now when I had a website set up in IIS for mydomain.com, and set my project's start up url (Local IIS) to mydomain.com, and then launched the project before remembering to add a record in the host files for the domain:
127.0.0.1 mydomain.com
This got me for a good hour before I remembered I never set the record. Adding the record fixed it right away.
Windows 7 x64, VS 2012
In my case, the Remote Debugging Monitor component was installed and the app was clearly configured to debug locally in settings. This was a WinForms app upgraded from VS 2008, .NET 3.5.
Turns out it was the Windows Firewall. By directly running:
C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE\Remote Debugger\x64\msvsmon.exe
A firewall dialog appeared where I could allow msvsmon.exe to run. After a VS 2012 re-start, debugging (locally) was fine!
Ensure you have Local Machine selected in this drop-down menu:
Windows 7 x64, VS 2012, VB.NET
I fixed it like this:-
Create a shortcut on your desktop to "C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE\Remote Debugger\x64\msvsmon.exe".
Right-click shortcut and select "Properties" from the dropdown menu. Select the "Compatibity" tab, tick "Run this program as administrator" and click OK
Create a shortcut on your desktop to "C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE\devenv.exe".
Right-click shortcut and select "Properties" from the dropdown menu. Select the "Compatibity" tab, tick "Run this program as administrator" and click OK.
To start VS2012:-
Double-click the msvsmon shortcut icon (that you created above, to launch msvsmon). Wait for the "Visual Studio Remote Debugging Monitor (Administrator)" window to display before continuing ...
Double-click the "Visual Studio 2012 Professional" shortcut icon (that you created above, to launch VS2012)
In VS2012, ensure standard toolbar is visible.
In VS2012, ensure "Solution Platforms" dropdown (on standard toolbar) is visible and set to "x86".
and debug now works (for me anyway) ...
However after 15 minutes or so, debug may stop working and you may get the msvsmon error again. If that happens, simply close VS2012 and msvsmon and then start again (from "To start VS2012:-" above) ...
Myself and several other developers have been trying to look for a solution for this problem for about 3/4 hours as Visual Studio crashed then this error would occur (twice in 2 days). I then suddenly (after a lot of debugging and trying other suggestions and headbanging) I somehow realised that the file which was highlighted had changed and when I was trying to debug was not the MVC app project, once I changed it to my project's one it then worked.
Hope this helps and saves people from hours of pain!
I also got this error, I usually run sites under a named user (which is also a database user) and forgot to set the Application Pool. (parliament's answer also helped me)
For me this worked in VS2013:
Save your work, close Visual Studio then reopen your project
I encountered this error as well.
The cause of mine was that I had accidentally emptied out the following property
Properties->Debugging->WorkingDirectory
Changing it to:
inherit from parent or project defaults
Solved the issue.
If you are using Microsoft's Azure, try attaching manually the debugger:
I have outlined the steps in the following answer:
https://stackoverflow.com/a/35738995/1057052
I'm trying to diagnose why my Outlook plugin written in C#/VSTO 3.0/VS 2008 doesn't load after being installed.
The plugin works awesomely on my development machine, which has Visual Studio 2008 installed. I can't expect all my users to have all the prerequisites though so I went through these steps to write an installer:
http://msdn.microsoft.com/en-us/library/cc563937(loband).aspx
I installed the add-in on a fresh Windows XP SP 2 machine with a fresh install of Outlook 2007. It installs all the prereqs ok (.NET 3.5, VSTO 3.0 runtime, Windows Installer 3.1, 2007 PIAs). Outlook starts but the add-in isn't run. If I go to the Add-ins tab in the Trust Center, I see my add-in in the "Inactive Application Add-ins" section with the message "Not loaded. A runtime error occurred during the loading of the COM Add-in.".
Not sure how to find the specific error so I can fix it.
The reg keys look ok. Under HKEY_CURRENT_USER\Software\Microsoft\Office\Outlook\Addins\BlahAddin I see Description, FriendlyName, LoadBehavior (set to 3 until it fails after which if becomes set to 2), and Manifest.
Tried the VSTO_SUPPRESSDISPLAYALERTS environment variable trick and then launched Outlook from the command line but no output came out.
I have remote debugging more or less working but I'm not sure what to look for. I don't see my DLL loaded when I attach to Outlook, but then again maybe managed DLLs don't show up the same way in VS.
Any other ideas on next steps I could follow to produce a specific error I can diagnose?
Solved my problem after weeks of pain. The "Manifest" reg key was getting corrupted to some junk value during the setup build. It was a known Visual Studio bug that supposedly got fixed in Visual Studio 2008 SP 1, but apparently wasn't for me. Renaming the project name to be different from the plugin name fixed the problem. Random, huh?
Make sure you have try-catch handlers at the top level of all methods called by Outlook and log any exceptions you are unable to handle in some way. Focus your troubleshooting on methods like the Startup method and other methods called during initialization.
You probably want to debug this using the remote debugger. Share out the MSVCMON.EXE folder from your developer machine (in your Visual Studio folders in Program Files) on your test machine (share it with a UNC path), and launch Outlook under the debugger trapping (.NET) exceptions in your modules and putting breakpoints in your methods.
If you need to clean your test computer each time before you install your solution, you should probably run XP under a Virtual PC 2007 VM (free download) and switch to a differencing HD after setting up everything but your plugin to snapshot your pre-installed state once so you don't have to keep uninstalling/reinstalling as you make changes to your program to fix bugs.
Are you installing Debug builds or Release builds? Perhaps one flavor has different requirements. Just guessing.
-Mike [MSFT Office Dev]
On your machine, when you run the addin from Visual Studio, it should create a registry key in HKEY_CURRENT_USER\Software\Microsoft\VSTO\Security\Inclusion{SomeGuid}. Make sure that these registry settings are also being deployed with your addin. They are the ones that allow your code to be trusted.
I have created a VSTO application using office 2005 & visual studio 2005 professional.I found there a setup folder.While i am running the *.exe file in client machine,it giving me error."An add-in could not be found or could not be loaded."
What is the architecture of the client machine?
If Vista: do you have the UAC (Security Dialog) disabled?
Also check in the Registry if the Path to the Manifest File is correct.
Is it loading the right Framework Version?
Are you using the Publish feature, or are you trying to create your own MSI?
You need to do some debugging on your side to have this sorted maybe:
Try to uninstall VSTO SE completely and install it again.
Create a new VSTO add-in without any additional code and run it.
Evaluate what happens and perform actions accordingly