I've been developing a large scale project independently for the past two years, and just today I started having problems under the hood.
I have a code library in which I write the majority of my code, and an external project that references the library to implement it.
Suddenly, when I attempt to launch the .exe from the release folder, I get an exception, however when I launch in release mode through visual studio, it works fine. I don't experience this problem in debug mode at all. It appears as though the library is properly rebuilding it's .dll and putting it in the release folder despite this behavior. I've tried everything from messing with properties to completely deleting all trace of the library, adding a new one, and copying only the code files into the fresh project, and I still experience the same behavior.
This is a very common issue related to environmental differences between DEV and Production systems. Chances are very high the Production system does not have the proper pre-requisite dlls on the system. You can determine the exact root cause of this problem by starting the Fusion log viewer, recreating the problem and reading the log. It will tell you what DLL is missing.
https://www.google.com/search?q=fusion+log&oq=fusion+log&aqs=chrome..69i57j0l5.1890j0j7&sourceid=chrome&es_sm=122&ie=UTF-8
Related
I have a 15 year old web forms app targeting .NET 4.6.1 that I'm maintaining, and I recently upgraded my laptop to VS 15.9.3. A release build of this app with 15.9.3 no longer fires the Application_Start event on production servers (running .NET 4.7.2). It runs locally just fine and I frequently deployed production builds from this laptop prior to the upgrade.
My desktop computer is still running VS 15.8, and a production build there works fine. The source code is the same between these machines, only the VS versions differ.
Symptoms and attempts at remedies:
I cleaned out all old files from production and tried setting it up from scratch. No dice.
Setup new application under IIS using the same build, but the outcome is the same.
Nothing in the event logs about any errors, except for the error that gets raised when some pages try to access state that's initialized in Application_Start.
I try to log some messages and even raise an exception right at the start of Application_Start, and I don't see anything, so Application_Start is definitely not running.
What can I do to further diagnose the problem? I haven't been able to find anything about this online, or why the newest VS release suddenly doesn't work.
Barring any remedies, any suggestions for downgrading VS instead of completely uninstalling and reinstalling the older VS?
Edit: now even reverting my laptop to VS 15.8.9 did not roll back the problem, so I've disassembled a build from both machines. There are few differences, basically the build number of a dependent assembly, the module version identifier, the comment designating the "image base":
Not working build:
// Image base: 0x055E0000
Working build:
// Image base: 0x052D0000
As far as I understand, none of these differences should have any observable effect. I then disassembled the dependent assembly that's built alongside the ASP.NET app, and it has the above differences and a few more related to the offsets for static field initializers. So I still have no idea why this might be happening.
Edit 2: it seems the issue is in the final aspnet_merge step while trying to merge the precompiled web forms. The merge fails in finding any assemblies to merge, suggesting that precompilation may have failed.
My app does not run on "Release x86" when running the app it crashes immediately after the splash screen. Output shows the following exception:
The program '[8204] dfz.exe' has exited with code -1073741515 (0xc0000135) 'A dependent DLL was not found'.
It also tells me the module is build without symbols, however in build settings I have set debug info to Full.
The first time I build the app for the Windows Store it built correctly and I also published that version to the store. When I did a manual rebuild to check if ads where inserted correctly it would not run.
However, I can run the app on ARM and X64 with no problems on release. Only x86 with .Net native toolchain will throw the missing dependant DLL.
What I have tried so far:
Created a new project, Added all my files and Nuget packages, No dice
Removed and updated all my existing references.
Tried to debug the release version so i can find out what DLL is missing from the package. However it keeps telling me there are no symbol files.
I am looking for any suggestions I can try because I am really at a loss here of why it will not run on x86.
Edit:
A blank UWP project also returns the DLL error when i run it. It looks like i have a broken development environment.
Edit2:
Just did a remote debugging session to another laptop and the app worked with no problems. So the problem is an environment related issue.
Could one of the projects in your dependencies be configured specifically for x64?
Another thing to check is that one of your projects is not set to build for that configuration (I vaguely remember some problem I had years ago that sounds kind like your situation ... although not for windows store apps ... and it turned out one of my projects wasn't set to compile for the configuration I was selecting ).
I currently have one solution that references ten .dll files. Those .dll files in turn all reference a shared .dll file.
Today I started getting an error while debugging that stated, "The source file is different from when the module was built error.", immediately following a recompile of the shared .dll.
I tried all of the usual. I deleted bin and object folders. I recompiled. I closed all instances of Visual Studio and restarted after they were all closed. I restarted my machine. Nothing fixed seemed to fix it.
I'm guessing one of your 10 DLLs references a different copy of the shared DLL, and not the one you compiled.
Since you have all the sources, put all the projects in the same solution, and have the DLLs reference the shared DLL's project. This will solve your problem.
It has happened to me too. Once I fixed it by recompiling project-by-project from ground up (in the same order that VS does).
Another time this didn't help. I can't remember what I did then.
I believe it is a bug in VS.
I notice you are running VS2008. The problem might go away with an upgrade (the supposed bug might have been fixed). VS2010 is also nicer to work with than VS2008 so it could be areason of its own to stay current. Why not download an evaluation VS11 and try it there.
Move all projects to one solution, reference them in a simple and correct way. Compile. Now you have the right DLLs everywhere and can go back to your more diverse solution(s).
You can also try to use MSBuild. It is easy since you already have the projects in VS. Once it is build by MSBuild (which VS uses itself) it should probably compile in VS again.
Finally you can try to build with nAnt. Once it compiles you can probably compile in VS again.
Good luck. I've been there. It sucks.
I suppose you referencing in your project directly to some DLL, and not a project. Which means if you even cleanup and rebuild, the same dll will be used like a reference.
Very often this is a problem, so I suggesting you check your references.
[edit] Assumed this was asp.net, disregard. [/edit]
Have you deleted everything your temporary .NET folders?
Either in:
C:\Windows\Microsoft.NET\Framework[Your Version]\Temporary ASP.NET Files
or
C:\Windows\Microsoft.NET\Framework64[Your Version]\Temporary ASP.NET Files
When comparing last-modified dates of the shared .dll across output folders of all of the solutions with the file that was stored in the output folder of the primary solution, I noticed that they were not the same as the file that I had just built.
This didn't make sense to me, so I simply copied the new files into the output folder. This did NOT solve the problem. On subsequent builds, the old version was again placed into the output folder, immediately causing the error while debugging...
During compilation, an older version was being pulled along with one of the other referenced .dlls. There is obviously some sort of check that is made with the names of files pulled in so that only 1 file is used, but no check is made for latest version number.
I was able to actually solve the problem by creating a reference to the shared .dll from the primary solution. Direct references are obviously (or perhaps hopefully) pulled in before files that are referenced by references (and are already copied into the same output folder as those referenced .dlls), so the latest file was successfully pulled in first.
If clarity is needed, let me know!
I rarely respond to posts since I am generally too busy, but I just spent a ton of time on this same exact problem. I am running VS 2008 in Windows 7. I had set the my Visual Studio to run in XP Compatibility Mode to fix some issues I had with a different project and forgot to reset it to NOT run in compatibility mode.
Once I removed the Run In compatibility MODE (In Windows Explorer on the DevEnv.exe) my problem with the source being out of sync with the debug information went away.
Hopefully this might help someone in the future with the same problem.
I am having great problems running the application in the debugger from Visual Studio 2008.
When I'm using vshost.exe, it says:
And when vshost.exe is turned of, it simply states:
Interesting thing about it is that when i do use vshost, debugger is actually started and breakpoint is hit on the first line of the Main().
I tried:
rebuilding the project(s)
removing .ncb, .suo, .user for the projects
repairing Visual Studio 2008
changing the build architecture for the project
... no help there...
Any experience in (trouble)shooting that?
More info: some projects DO work, and one that I have to work on, does not.
I have some ideas such as:
trying to create NEW project, add thing by thing to it and see at what point it will start to miss behave
work it other way around, delete project by item by item to see when it will (if it will) be working OK again.
EDIT (for google, as I see that there are many similar questions on the web):
Errors:
Error while trying to run project: Unable to start debugging.
and
Error while trying to run project: Unable to start program '....\PlayKontrol.exe'
Try upgrading your Visual Studio to Service pack 1, if you haven't already.
Did you restarted your computer? You never know how windows will react to that :).
Also be sure there aren't any keys stuck, like the ctrl or windows key.
Note that the key does not have to be visually stuck, it can be stuck for visual studio and not for the explorer.
The most common source of sudden problems like this is corruption of one of the data files that vs uses to cache information between builds.
You've tried a clean build, but this won't delete everything. A real clean build is: quit vs, delete bin, obj, debug, release folders, delete all generated files in the root - primarily ncb. Do the same for any locally built libraries that you're project references.
The easiest way to do this is if you have the code in source control, as you can rename away your entire code folder and then force a get of all the source.
You often need to do all of these things in one hit to clear the problem.
Less frequently, a reinstall of vs will sort things out (although this sounds unlikely in your case if it is only one project that breaks)
Also think carefully about anything you might have installed just prior to it failing... And remember that some install effects may not occur until the next reboot so it could be days ago. A particular cause of this are automatic windows updates and trial versions of things like the vs 11 beta.
You might try running the application from outside of VS, but have a line of code that looks like this: Debugger.Launch(); where you want your first breakpoint.
I'm coding an application on C#, and it runs perfectly fine when I click the "Run" button in Visual Studio C# Express 2010. But, when I go to Debug -> Build Solution, after I run the .exe file, it says "XXX.EXE has stopped working..."
I have inserted break-points and commented out chunks of my code, rebuilt the project, and ran again to try to isolate the problem, but I can't figure out what is causing this. The fact that it runs fine in debug mode is strange.
Some things to try:
Check the system Event log for ASP.NET errors.
Try setting the build to Release mode and using Run--no debugging. See if it crashes then. Watch the Output and other windows for any errors during/after the crash. Depending on those results, check that your solution and project properties are correct in both Debug and Release configurations.
You can also build in debug mode, launch it externally, than attach the Visual Studio debugger to the process. But of course if it crashes on startup than that won't work.
You can add Debug.Assert lines to see if you can get one of those to throw.
Wrap your code in a big try/catch and make sure your catch handler somehow reports or logs the full exception for you.
Adding logging would be good idea. You can log to a file or the system event log. I suggest log4net or similar logging tool for that.
I just had this issue and was going to see if I could catch when the error happened via a console window, when I changed my app to console based the program stopped crashing, I commented out all Console writes and set it back into a windows forms app and voila, runs fine now.
-I know its an old post, but its open and unanswered so I think its fair game.
Try adding your application to your Antivirus Whitelist or exclusion list. This is a known problem with McAfee and Avast!
I may be misunderstanding the problem, but if you are trying to run your app from its .exe file (originally located at Visual Studio ####\Projects\ProjectName\bin\x86\Debug\ProjectName.exe), you must make sure that that .exe file is in that original directory. You cannot move it. I ran into a similar problem with XNA projects. If you want to move the.exe file somewhere else, you can create a shortcut to it, but don't ever move it. If you try and run it from a different location, or if you move any of the other files from that directory, you'll get an error message exactly like the one you described.
Also note that some Visual Studio projects (like XNA ones) will not run as standalones. Building the projects doesn't export them into a standalone format, they can only run on computers that have VS and all the projects framework installed, and their .exe file must remain in its original place.