I encountered a hell problem when I attempted to invoke “LoadLibrary” in C# environment. The application was crashed when I pressed “Ctrl + F5” and entered the directly running environment, but it was certainly O.K. if I pressed “F5” entering the debug mode. I tried to directly run the application, it had the same errors. There are some test projects in attach files, I thought that it was enough describing the issue. How did I solve it?
Ps: The solution’s environment must be set to “Debug” and the compile form must be “X64”, then the ConsoleApplication2 project is “Startup project”.
I tried to use the “LibraryEssential” project to invoking the “MathmaticPower” function which was in “MathmaticLibrary” project. But my C# project “ConsoleApplication2” loaded “LibraryEssential” dll file by “PInvoke LoadLibrary”.
Some improvements: I tried to run the C# exe application in "Administrator", It's O.K., but I run it with other user, it's failed! Shall I must run the application in administrator role? I don't want to do so. Have any other ways for the issue?
attach files: LoadLibrary.zip
Related
Sorry if this is a duplicate -- I've looked at this and this and others, but I can't find my problem.
A program I build debugs successfully on my local machine, but when I try to debug it remotely, I can't set breakpoints in my code. I've opened the modules window in the debugger, and under Symbol Status for my executable, it tells me "Cannot find or open the PDB file." I try to load it manually, and get the error, "A matching symbol file was not found in this folder."
I created a minimal (hello world) app, and I can debug that, so I'm able to reach the remote PC. Indeed, the app does start up and run on the remote system. So, it isn't an access issue.
Not sure what else to say about this, other than to show you my project debugging configuration:
Any ideas are MOST welcome. Thanks...
Well, I found the answer -- I needed to check the "deploy" box in the Configuration Manager window. This surprised me a little, as using the "deploy" command (available from right-clicking the project property) didn't do the trick. Evidently, there's some behind-the-scenes magic that takes place when the deploy box is checked.
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 modified my vb6 project to support unicode by using CyberActiveX UniListView100 (UniListView.ocx) controller. I updated my listview with uniListview and project is working well on my machine. But when I try to run it on another machine, it is giving 'Error in Loading DLL' error right after I click on the 'Step into' or 'Start' button.
Once I tried with VB Common Controls Replacement 1.4 Library and the similar scenario happened there as well, code is only running on the machine where it created. But all machines I tried to run this code are equally set-up.
What can be the cause of this error? I even have registered the UniListView.ocx file in the Windows/SysWOW64 folder.
I tried to identified what is happening here with Microsoft Process Monitor, but I was unable to find anything from its logs yet.
Please tell me what can be the cause for this..
Often, the DLL in question is a dependency of the DLL you're trying to load. Find and use the Depends utility to see who requires what. You run Depends, Depends runs your process. First run it on your machine, then on a failing machine. The differences are usually obvious.
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.
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.