I am using Power Automate desktop.
I run Visual Studio 2017 using run application and I get the following error :
Can't retrieve main window handle for application
What do I do and how?
Please be specific .
It's 2022 and all the other answers are not up do date
thank you.
You can modify the parameters to avoid the error. Sometimes the window handle is not resolved after running an application and hence this kind of error can occur if we wait for application to load or complete. In my case I modified the below parameters, and the error was resolved. Snip of action
Related
I am facing an issue, I am writting a script to automatize some part in a project.
Basically, it builds a website: building the front end part, creates in IIS the application, virtual directory, application pool and then build the back end part.
But I have an error when I try to access it (here the error in the event viewer (and I don't have anything more)
event viewer error
(For info the folder "bin\ISSSupport" does not exist at this very moment, it is only created after the fix explained below)
To fix it I just need to execute IIS launcher in visual studio:
IIS launcher
I would like to know if there is a way doing this action with command line.
(Or even better if you know a solution to my first problem)
I was using VS2005 previously for two web applications and was deploying the applications using vs2005 cmd prompt. But I recently migrated to VS2013 and the same nant scripts commands are not working fine when I execute them using vs2013 cmd prompt. I'm getting the below error message in at the time when it fails
External Program Failed: aspnet_compiler.exe (return code was 1)
Can somebody please help me out with this thing. One application says successfull but when I open the application using the url it says page not found.
I finally got it resolved it is the problem with versioning. VS2005 dev cmd prompt by default picks aspnet_compiler from v2.0.50727 however VS2013 dev cmd prompt by default picks up from v4.0. So I replaced
program="aspnet_compiler.exe" with program="C:\Windows\Microsoft.NET\Framework\v2.0.50727\aspnet_compiler.exe" and it solved the problem for me.
Thanks all
aspnet_compiler will compile all the views (*.aspx, *.ascx, *.cshtml, etc). It's roughly akin to running each page and validating it renders correctly. This is a great way to validate all your pages are free from hard-to-find run-time errors. Since aspnet_compiler ran, the issue isn't that it isn't in the path. It may be that it's using VS 2005's aspnet_compiler or from a different framework version, but that's less likely. More likely is that you have a syntax error in a page or user control. Look at the build output around the "return code was 1" message and find the additional detail about the page and line that is failing.
Another not-recommended option is to comment out the aspnet_compiler line from your nant file, but you then lose all the benefits of this precompilation / validation.
Using Visual Studio 2010 beta, when I run my application within the IDE for debugging, it works perfectly the first time. However, after closing the debug session, either by closing the application or clicking the stop debugging button, all subsequent attempts to debug the application fail with:
Error 1 Unable to copy file "obj\Debug\Application.dll"
to
"bin\Debug\Application.dll".
The process cannot access the file
'bin\Debug\Application.dll'
because it is being used by another
process.
Handle.exe from SysInternals does show handles open, but even if I close the handles, the error doesn't go away. Any attempts to delete the file manually result in an "Access Denied" error message.
To fix this, I have to completely restart Visual Studio, afterwhich the Debug session will work once and stop again.
I'm not entirely sure when this started happening, but I'm pretty sure it's fairly recently.
UPDATE: After I force close the handles on Application.dll, I get the following error from VS:
Error 1 Unable to copy file
"obj\Debug\Application.dll"
to
"bin\Debug\Application.dll".
The requested operation cannot be
performed on a file with a user-mapped
section open.
What the heck is a "user-mapped section"??
UPDATE 2: It appears that this problem occurs when I have a Form open in Design view when trying to debug. I'm going to do some more troubleshooting and then post my results.
UPDATE 3: I think I've narrowed it down to a form using a UserControl.
To be honest with you, it sounds like a bug in VS2010. For some reason it isn't closing the open handles when the debugger stops. Killing the VS process automatically closes those handles, allowing you to access the file again. As a work around, you might look at unlocker it's free and works exceptionally well. I know that's not a great answer, but it should be faster than restarting VS. You might to consider sending a bug report too...
Unlocker doesn't work on 64-bit OS, LockHunter does though.
Here is how I solved this problem
*I open the project Properties,
*select the build tab,
*Clear the output path,
*and buid(this will create the dll in the root folder)
*come back to the output path and select browse(browse to the bin directory to either debug/release)and voila!
As per Error: Cannot access file bin/Debug/… because it is being used by another process answer by TarmoPikaro, sometimes Visual Studio creates multiple msbuild.exe ghost processes, which persist after build. These ghost processes seem to be causing file locks.
Solution 1 - Kill ghost MSBuild.exe's
Killing msbuild.exe's is a one time solution, it needs to be done per build basis.
You can kill the processes as follows mrtumnus:
taskkill /f /im MSBuild.exe
Solution 2 - Disable parallel builds in Visual Studio
You can disable parallel build once and for all:
Tools > Options > Projects and Solutions > Build and Run > "maximum numbers of parallel project builds" - by default it has value of 8, switch it to 1.
Of course builds are bit slower now, but mileage may vary depending on your use case.
This is related to
Error: Cannot access file bin/Debug/... because it is being used by another process
I've seen the Windows Indexing Service cause this. Disabling it helped. Virus scanners can also be at fault. Mutliple Application.Close() calls can supposedly cause this, too.
Of course, since it always works the first time, I suppose these are unlikely.
Had the same problem. The following things helped
Closing all design files while debugging
using unlocker
Also my application opens a port. While debugging an exception was thrown and program quit. While ending the program I closed the port. That helped too.
But definitely, bug with VS2010.
I encountered the same problem and in my case I had the file in question open in Visual Studio. Closing all files helped.
I faced the same error and I was stuck in it for many days. Finally resolved the issue.
I was working on a project that had many class libraries added in it. I added the reference of these libraries to my main project and mistakenly added reference to same project to itself. So when I removed self reference, it worked.
I had this issue myself. I had the project properties window open and that apparently creates a file lock. Even after I closed the window the file lock remained and I had to restart VS.
P.S. I'm using VS 2019. Just posting this for anyone having the issue I had and coming to this post.
If you get this error on VS Code;
Click on terminal screen and use "Ctrl + C" for stop running.
Ive got a C# 2.0 app that launches the Crystal Reports viewer and displays some reports. If I run this in Debug or Release mode OUTSIDE of visual studio, it runs fine. If I debug this through Visual Studio 2005, the report will pop up, but then a minute or two later VS freaks out on a ContextSwitchDeadlock, also telling me that no symbols have been loaded for any call stack frame so i can't debug it.
This likely has something to do with the fact the report is being launched on another thread. The reasons for this are a little convoluted but I'll try to explain in case it's important:
We have a long-running process that runs on a background thread. When the process is done it launches reports. If it(the background thread) just calls Show(non-modal) on the report viewer forms, it will then terminate and kill all those report forms immediately. So instead it launches one child thread per report and calls it with ShowDialog(modal). That way the forms are all seemingly non-modal to each other, but when the user closes the LAST one, the background process thread now has no child threads and it can terminate.
Does this makes sense, and does anyone have any idea why I'd be getting the ContextSwitchDeadlock MDA inside VS, but no exception is thrown when the code runs standalone?
Try renamining you c:\temp\ directory - There is a know issues that if there is an XML file in the c:\temp\ Crystal Reports Crashes and you cant open them..
I think you answered your own question... it has to do with how your running it in a separate thread.
Delete or move any .xml files in your c:/temp folder if you have one. They cause database expert to crash VS
Got the same problem. It's been known to cause database Expert to cause VS to crash also due to some xml file being in your c:\temp directory. First option is, to empty the c:\temp directory (worked for me). Second you can try to rename your temp directory to "MyTemp" or something similiar. And last but not least you can try setting your project to use 4.0 Framework not the client version.
P.S:#John Cruz Nope he didnt, I don't work with separate threads in my project and got the same ContextSwitchDeadlock-Error.
I am working on an application that installs a system wide keyboard
hook. I do not want to install this hook when I am running a debug
build from inside the visual studio (or else it would hang the studio
and eventually the system), and I can avoid this by checking if the
DEBUG symbol is defined.
However, when I debug the release version of the application, is
there a way to detect that it has been started from inside visual
studio to avoid the same problem? It is very annoying to have to
restart the studio/the computer, just because I had been working on
the release build, and want to fix some bugs using the debugger having
forgotten to switch back to the debug build.
Currently I use something like this to check for this scenario:
System.Diagnostics.Process currentProcess = System.Diagnostics.Process.GetCurrentProcess();
string moduleName = currentProcess.MainModule.ModuleName;
bool launchedFromStudio = moduleName.Contains(".vshost");
I would call this the "brute force way", which works in my setting, but I would like to know whether there's another (better) way of detecting this scenario.
Try: System.Diagnostics.Debugger.IsAttached
For those working with Windows API, there's a function which allows you to see if any debugger is present using:
if( IsDebuggerPresent() )
{
...
}
Reference: http://msdn.microsoft.com/en-us/library/ms680345.aspx
Testing whether or not the module name of the current process contains the string ".vshost" is the best way I have found to determine whether or not the application is running from within the VS IDE.
Using the System.Diagnostics.Debugger.IsAttached property is also okay but it does not allow you to distinguish if you are running the EXE through the VS IDE's Run command or if you are running the debug build directly (e.g. using Windows Explorer or a Shortcut) and then attaching to it using the VS IDE.
You see I once encountered a problem with a (COM related) Data Execution Prevention error that required me to run a Post Build Event that would execute editbin.exe with the /NXCOMPAT:NO parameter on the VS generated EXE.
For some reason the EXE was not modified if you just hit F5 and run the program and therefore AccessViolationExceptions would occur on DEP-violating code if run from within the VS IDE - which made it extremely difficult to debug. However, I found that if I run the generated EXE via a short cut and then attached the VS IDE debugger I could then test my code without AccessViolationExceptions occurring.
So now I have created a function which uses the "vshost" method that I can use to warn about, or block, certain code from running if I am just doing my daily programming grind from within the VS IDE.
This prevents those nasty AccessViolationExceptions from being raised and thereby fatally crashing the my application if I inadvertently attempt to run something that I know will cause me grief.