I recently refactored some code, and a method the original Global.asax.cs file was depending on was no longer static. When I made changes to my Global.asax.cs code to fix the compilation problem, VisualStudio Development Server is still reporting the old problem. To make things more confusing, it's reporting the old problem with the new source code.
When I start up the development server I get the tell-tale error screen saying:
Method not found: 'System.Security.Principal.IPrincipal Example.Records.AuthenticationManager.GetPrincipleForUserName(System.String);
This original exception was located at line 54--which shouldn't matter to you, me or anyone else. However, it matters to Development Server. No matter what I change the code to, even completely commenting out the original code, I get the same error message. The only difference is the snippet of code it displays. It's currently pointing to a comment line.
So DevelopmentServer is seeing the old compiled code and VisualStudio is seeing the new code. I can't set the breakpoint because VisualStudio is telling me the source code is different from the original version.
How can I force DevelopmentServer to see the new code that works?
I have since found the real reason why this occurs, and it also affects the "Symbols not loaded for this class" problem when you try to debug your application. The problem has to do with the path to the DLLs. If your web application is part of a larger solution, and someone edits the solution configuration, Visual Studio will alter the build output path.
By default, the build output path for Debug is located in the ~\bin\ folder. This is so that Cassini can find the DLLs and the PDB files. When someone edits the master configuration and changes the architecture, VisualStudio will automatically update the target output directory to "~\bin{architecture}\Debug". You have to manually go into the properties for your project and set the output directory to "bin\" for debug again. Once you do that, it will work again.
--- Original Answer:
The only thing I could do to make it work was create a new project and copy all my code in. It's not a good answer, but its the best I could come up with. Same exact code ran like a champ. After going through the project file line by line, I could not find anything that would explain the behavior I was seeing.
Related
I have a MVC5 project that is currently set on the "Release Configuration" and it works 100%. However, as soon as I switch the project configuration from Release to Debug, then everything goes wrong... even if I switch it back to Release mode, everything is still broken. Only way I can get the project working again is to restore from a backup.
Here are what is happening.
Firstly, when running the project, I get the following error:
BC30451: 'ViewData' is not declared. It may be inaccessible due to its
protection level.
If I open any view in the project with Visual Studio 2013, I can see that all sorts of things are marked as errors like ViewData, Html, Url, etc.
When referring to #Html or #ViewData in the view, it normally refers to the .Html and .ViewData properties of the view's base class (WebViewPage). However, if I start typing "#Html." in any of the views, I can see in the autocomplete that it is referring to the System.Web.Webpages.Html namespace instead of the WebViewPage.Html property. It is as-if the view isn't inheriting from the System.Web.Mvc.WebViewPage class.
Any guidance as to where I can start looking to get this fixed or why this is happening?
Edit:
So since nobody responded, I went through the long way. I created a brand new MVC5 project, added all the packages via Nuget and then simply copied all my files over from the old project to the new one and now it works.
Does anybody have any idea what the heck could be causing this? I don't want to go through all this trouble again in the future if the project again suddenly decides to stop working.
Ok, I think I've found part of the cause here. Thing is, since the original code is valid (it compiles correctly and intellisense picks it up) and the code used to work and then all of a sudden, one day after compiling, it just stops working.
Anyway, in the view, when specifying the ModelType, if you don't use the full name, this error can occur or occurs eventually.
For example, using:
#ModelType Models.SomeNamespace.SomeClass
will cause the error (even though the Root Namespace for the project is "MyProject") and it can be fixed by simply specifying the full namespace and class name.
#ModelType MyProject.Models.SomeNamespace.SomeClass
It's possible that a debug assembly is locked. Can close Visual Studio, search and delete for all bin folders in the solution directory. Then open and rebuild.
The other options is to go into the MVC project properties and compare the two build configurations. Are you targeting a different .NET framework between Release and Debug? 32 bit vs 64 bit? etc?
Looks like some MVC assemblies are corrupted.
Have you checked your referenced assemblies for some errors?
Try also cleaning all the .NET internal cache. More in this stackoverflow topic: Could not load file or assembly ... The parameter is incorrect
In my case imported ViewModel class name was incorrect, correcting it fixed the issue.
I've got a group project built in Delphi XE2 that has 3 projects that always build to the wrong folder for one option set. (I've got 4 configurations under Release and Debug, one for our software configurations and one for FastMM and it's only the debug one that I want to use for debugging that always goes in to the wrong folder. Compiling the project even says it's building to the correct folder, but the DLL always winds up in a different one which I only used once when I was unit testing the code outside of the main project.
I've deleted every associated file, .identcache, .res, .tvsproj (whatever that was) and nothing changed. One very strange thing I noticed is that I copied one of the projects to configure the second one and mimics the behavior of the one it was copied from and I never even unit tested that one, so it never had that output path configured for it.
Obviously this makes it pretty annoying to debug, I have to copy files in to the correct folder just to do that (I was kind of astonished when it actually worked, because I thought Delphi might expect to find the files in it's output path, but oh well, those things are magic)
Let me know if I can post anything to help, I don't really know what's necessary, I checked the registry for the output path that it is getting built do and found nothing that I thought was of any consequence (nothing related to these projects).
One thing I did notice was, because I copied the original project into another project (they're plugins to the same part of the main program) it has the same and when I try using it in the "Build Group" it automatically selects both projects. That's one mystery solved, but is probably a red herring?
OK so as usually happens, after 3 years of suffering with this when I finally ask the questions I'm lead straight to the answer it appears as if RAD Studio is lying to us. The configuration shows this:
but the dproj had this:
in it.
there were two conditions for cfg_3 and only the last one showed up in RAD Studio, well for some odd reason the build path was taken from the first one (even though it's specified in both). So, removing the wrong one (the first one) fixed the problem and things are now building to the correct folder.
I had imported the Utils option set when I was testing the library, but when I incorporated the program in to the main program, I removed it. Somehow it didn't find it's way completely out of the dproj and I guess (not sure why) but it seems like the other library got messed up because it shared a GUID.
Sometimes Visual Studio does not allow me to set breakpoints in MVC views. This has happened to me scores of times, but it doesn't happen for every view and I don't know why.
When you click on the left-hand bar to place a breakpoint, it places a white circle instead of the normal red circle. The message when you hover over it is "The breakpoint will not currently be hit. The source code is different from the original version." It goes on to describe how to allow breakpoints to be hit, but that produces strange results and I don't want that anyways.
If the error is correct, then I want to run the original source code. I don't know what's going on behind the scenes in VS; I try rebuilding and all that but it doesn't help. I'm running in Debug mode in VS 2012.
This could be caused by many things, but a few items to check which I've helped people with recently:
First step: there must be a PDB file alongside the DLL to enable debugging. (see: What is a PDB file?) Make sure you have the PDB in the executing directory.
Clean to remove all the old DLLs from your bin folders.
Ensure that your application is running a build of your current code (the same version you have in Visual Studio). Don't assume that it is just because you clicked 'build' or 'deploy'. If no changes were detected then things often don't happen. Check the build time of the assembly, or change something and rebuild to see the file size change.
If you're running something web-related, make sure a browser isn't caching code, or IIS isn't holding a long running process.
Kill any running Visual Studio Development Server instances (you can do this from task manager, or more simply from the system tray - they look like an IE logo and when you hover over them they'll tell you which port they run on).
Restart IIS using iisreset from a command prompt.
Check the settings for Debugging in Visual Studio (Tools > Options > Debugging > Symbols) You want to automatically load symbols, and if you're linking other assemblies you need to reference their PDB files here.
So I had this issue this morning and the fix for me was related to razor syntax.
I was setting a variable inside an if statement
#If (my condition)
{
myVar1 = "blah blah blah"
#myVar2 = 1 <== This line here was causing my razor to crap out on render
}
So all of the other things are good things however, improper razor syntax can also cause the breakpoint issue. In this case it was the # symbol on myVar2 inside the code block... Just an FYI
The simplest solution I've found to work around this problem is:
Set a breakpoint in the controller code that is right before the View is called. Then, when that breakpoint is hit, step through (using F10) several times. It will go through _ViewStart.cshtml and maybe another thing or two. But soon it will get to the view.
Once you are in the view, then hitting F5 (continue) will take you to the breakpoint in the view.
Fom the answer nothing worked for me to set a breakpoint in the javascript code.
I moved the javascript code inside to file Scripts\myscript.js and replaced the script block to
<script src="#Url.Content("~/Scripts/myscript.js")"></script>
To add to #kirk-broadhurst answer, (please amend if possible), double check your web.config, specifically the compilation flag under system.web. Even if you are building for debug, if the debug attribute is set to false, you will run into issues debugging Razor.
<system.web>
<compilation debug="true" targetFramework="4.6" />
</system.web>
Make sure that "debug" is set and Voila ... debug is working again:-)
Make sure your Solution configuration set to Debug not on release.
Thanks
I have done all the searching and can't find a solution to this weird problem that's been bugging me for about 5 hours. I started this app in Lazarus, but then took it across to D5pro to see if I could solve the problem. Thought it might have been a Lazarus "thing."
In D5, I have an app fully-working (so far so good) and I decided to try some different approaches to the look and feel so I "Save Project As" into a new folder. I then went through all of the included Units and saved them to the new Folder. I copied the two OpenSSL .DLL to the new folder. Did a compile and run and it all works fine. Well, almost.
When I tried the new app, the POP3 Unit crashes at "Login"
I have stepped through and all of the basic login stuff, Server, Name, SSL parameters etc is identical to the former version.
I went back to the original app and did a full Build and it still worked fine. I did a full Build on the new app and it still crashes at Login.
It gets through the pop3.Sock.SSLDoConnect() OK, but comes back from pop3.Login() with an error 10061 which according to the BlckSock Synapse-Unit, means "Connection refused."
When it returns from this call Result:=ssConnect(s, #name, SizeOfVarSin(name)); which I assume is in the .DLL it has a Result of -1 which then triggers the GetLastError and that is "10061 - Connection refused"
As far as I can find, everything is identical between the two projects. All Library Paths are in the Environment and not within the project.
Any thoughts and suggestions?
There is not much to work with. Can you see all parameters in the debugger on the various external call moments?
A change of compiler of course can make hidden bugs come to the surface, just like e.g. optimization. A well known difference is that the life time of temps might vary (see here).
Probably you need to nail the defining difference first. As with Delphi, the debugger is your friend here.
OK, problem solved.
Sir Rufo, it was a good idea but it did not help, but thanks for trying.
I had copied the ssleay32.dll into the new app folder BEFORE I started compiling. It did not work. I did a full Build and it still did not work.
I decided to delete the ssleay32.dll and libeay32.dll and do a full Build. I ran it and of course it crashed, but this time I expected that.
I then copied the two .ddl back into the new app folder and did another full Build.
Bingo problem solved. Seems weird but it is working with both Lazarus and D5. Something to do with the way the .dll gets linked into compiled .dcu.
Doing the Build with no .dll available cleared that. Dropping the .dll back into the Folder and another Build got the .dll linking correctly included into the .dcu.
Aaarrggghhhhh :)
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.