I have a solution with a lot of project.
Few of them are using EDMX.
It looks like I did something that crashed my EDMX files.
When I open EDMX and click option "Update Model from Database" I get a exception popup windows with message:
"An unexpected exception has occurred. The exception message is: 'Exception has been thrown by the target of invocation.'."
And interesting is it doesn't matter which project. Any EDMX in the solution give me this bug. I have VS 2015 with latest EF 6.1.3.
Please help me :)
not sure if any one else is still having this issue. But I found a possible solution.
Open View > Server Explorer. then open the 'data connections' node and delete any connections in there.
This seemed to have fixed it for me.
I ran windbg.exe as well and found it was throwing an exception in Microsoft.AspNet.SignalR.WebSockets.WebSocketHandler
Hope this helps
Related
Using EF 6.1.1
(Reinstalled VS2013 + Update) x4
Happen at each web application project
Transcript:
Error
There was an error running the selected code generator:
'Object reference not set to an instance of an object.'
Just looked up everywhere on the internet, and nothing works, like:
Restarting VS
Reinstalling VS
Executing Install-Package MvcScaffolding
Creating another project
Checking database if exists
Searching the internet
Crying
Now, posting on SO
I'm running out of idea for how to resolve that Helpless error
NB1: My database is created using an *.edmx file and SSMS
Thanks for future answers/hints
What DB do you use? I was having similar problems with MySQL, but I was using additional extensions for that DB. (Solved that by reinstalling several times the extension and saving the .edmx every time in source control while working so when it crash can revert it back :) )
Please check the answer of similar question (hope that helps): Scaffolding controller doesn't work with visual studio 2013 update 3 and 4
After having so much issues with .edmx - do not use them... I know is much more code writing but then you can more easily control and modify it when the db design has changed.
Ever since upgrading to Visual Studio 2013 (From 2012), I've noticed that while debugging my ASP.NET MVC 5 app, I'll occasionally get a compiler error dump through IIS Express of:
Description: An error occurred during the compilation of a resource
required to service this request. Please review the following specific
error details and modify your source code appropriately.
Compiler Error Message: CS0042: Unexpected error creating debug
information file 'c:\Users\Jeff\AppData\Local\Temp\Temporary ASP.NET
Files\root\368a9040\83fb9039\App_global.asax.PDB' --
'c:\Users\Jeff\AppData\Local\Temp\Temporary ASP.NET
Files\root\368a9040\83fb9039\App_global.asax.pdb: The process cannot
access the file because it is being used by another process.
Source Error:
[No relevant source lines]
Source File: Line: 0
This error goes away if I open up Process Explorer and then search for the handle to App_global.asax.pdb (that DevEnv.exe has) and forcefully close it and then refresh the page. However, that's inconvenient and I've never had to do that before 2013.
Anyone have an idea on why this is happening intermittently on 2013 but not before?
The only possible thing I could think of was some obscure issue with Razor Generator's MSBuild step that I use, but I couldn't figure why it'd be on the App_Global.asax and not a view (and even then, it shouldn't be compiling for an unmodified view)
After upgrading to VS2013 we ran into this issue on a large webforms application that we develop. We solved it be removing the optimizeCompilations="true" attribute from on the compilation element in our Web.Config file.
I also tried VS2013 Update 1 and VS2013 Update 2 RC and neither of them resolve this issue.
I'm not sure if our issues are identical, but I solved the issue for me by disabling Edit and Continue.
Tools -> Options -> Debugging -> Edit and Continue -> Uncheck "Enable Edit and Continue" .
After installation of Delphi 6 at new working station I issued problem with breakpoints. In debug mode environment doesn't trigger breakpoints like they are not placed at all...
Have you experienced similar situation? I suppose reason is some setting, but I cannot find which one...
TnX in advance!
Nemanja
Yes, this sometimes happens (not only in 6).
Enable all debug information except debug DCU's unless you want to debug the Borland code. (Don't forget to check for compiler switches in the code).
Disable code optimizer.
Rebuild all code.
If you are using DLL's be sure to enable debug code in all projects and set the host application to the right executable.
If that fails.
Be sure that there are blue dots at the code.
Be sure you have the right source file. You can check this by adding an error (for example dghasgsgd) and recompile, if the compiler accepts, this is not the right source file.
Be sure the code is reached (add a SendMessage statement or a message box so you can be sure the statement is reached.).
Restart the compiler. Or even restart the pc.
If that fails.
Take a break. Have a lunch or get something to drink.
Return and show the problem to a coworker. (preferably a programmer too).
I applied all settings that #Gamecat suggested, so you can look at this answer like short addition to previous answer.
I missed only one more to solve my problem. In Tools>Debugger Options I checked Integrated Debugging which alive my breakpoints. When breakpoints started to work, I got error message 'Project _.exe raised exception class EAccessViolation with message 'Access violation at address 4CDEB080 in module 'IDPDX32.DLL'. ' For solving this issue I just unchecked option 'Stop on Delphi Exceptions' in menu Tools>Debugger Options>Language Exceptions.
Now Delphi works fine and don't need to reinstall it.
Reason for loosing my previous configuration that worked fine might be in copying my files from one folder to another (as well as config and other temp files) when paths became wrong and after that I probably deleted old config files and started with settings from beginning...
+1 Tip: If you get this message: [Error] RLINK32: Unsupported 16bit resource in file ....\estands\estandar_StdFormMainFrm.DFM problem is in Text-DFM option. When you right-click on the form in the IDE, is the menu item "Text-DFM" (or maybe called "Text as DFM") checked? If not, do so, save and try to compile.
If somebody knows reason for this behaviour, detailed explanation would be useful. Until now I found this option is for backwards-compatibility to older Delphi-versions.
In all MVC projects that I can remember (I'm now on version 3) I get the error:
A first chance exception of type 'System.Globalization.CultureNotFoundException' occurred in mscorlib.dll
appearing in the Debug Output pane when the project is run. Thus far I have ignored it because it seemed to make no difference, but ultimately I don't like errors appearing even if they have no apparent effect.
All exceptions are appearing in Debug mode, even those that are handled. When an exception is thrown in Debug model Visual Studio stops the execution and alerts you for this exception even if it is properly handled by your code. If a first chance exception is properly handled you can safely ignore it. You can disable first chance exceptions in Visual Studio.
Don't know if was a issue only in my machine, but enabling the following config, solved the case.
Debug -> Options -> Debugging and check Enable Just My Code (Managed Only)
StackOverflow Reference
Today, everytime I try to open any .Net application I get:
CLR error: 80004005
The program will now terminate.
Any suggestions?
I'd start with downloading and re-installing the .NET framework.
I had this problem and uninstalling/reinstalling dot net didn't help.
Randomly I found a suggestion to go to
c:\Windows\Microsoft.NET\
Then rename the directory called "Assembly" to "Assembly2" or something so you don't erase it but dot net will think it's gone.
After doing that, install dot net again.
This took hours for me to find and was the ONLY thing that worked.
I believe 0x80004005 is (usually) an ACCESS DENIED error - so start with that in mind. If you're on Vista+, try running it as admin. Otherwise, Process Monitor should help you track it down.
A quick search suggests this:
"If you get a Run-time error 80131522
"No Server registered or could not
load class for CLSID ...", it is
because you are trying to run the VB
executable from a directory other than
where the .NET assembly is located.
This also happens if you try to run
the vb code in interactive mode. This
can be solved by installing the .NET
assembly into the global application
cache"
(http://bytes.com/forum/thread353655.html)
In an ASP.NET context, it appears this is related to file permissions:
The error code for the failure is
80004005. This error can be caused when the worker process account has
insufficient rights to read the .NET
Framework files. Please ensure
(http://weblogs.asp.net/jambrose/archive/2004/09/01/224226.aspx)
#MarkBracket: I had a similar issue, but I think I finally fixed it thanks to Process Monitor.
My Solution:
Go to "C:\Windows" and right click on the "Microsoft.NET" folder and click Properties.
Click the "Security" Tab, then click the "Advanced" button.
Click the "Owner" Tab, then click the "Edit..." button.
Select your current user account, then check the box that says "Replace owner on subcontainers and objects" and then click "Ok".
Problem solved (for now at least).
As it turns out, the programs simply didn't have the proper permissions needed to run.
Anyways, Thanks Again Mark
I hope this post is helpful to any and all who have/get the CLR 80004005 error.
Just want to answer this from development prospective, as I got into such problem and solved it.
The problem I had encountered was that I was deploying a WPF application on a none development machine, It crashed immediately with the message "Fatal CLR Error 80004005".
I realized that I compiled my application as .Net framework 4.5 and I was using an API call from System.Web namespace.
I solved it by changing the method call and then re-compiled it as .Net framework 4.0 Client Profile.
I had the same error pop up when I had a lot of other applications running. Closing some of the more memory-intensive programs caused the error to go away.