I've got a web app deployed on Azure and I'm getting an error on the Azure deployment that shows the reference to a class library in the same solution.
But the error message shows a file path on my local:
Object reference not set to an instance of an object.
XXX.Domain.Concrete.EFBusinessRepository.PrepForConversionToHtml(XXX x) in c:\dev\repos\Jeff\ClassLibrary\Concrete\EFBusinessRepository.cs:1280
and not one more typical to Azure:
Object reference not set to an instance of an object.
XXX.Domain.Concrete.EFBusinessRepository.PrepForConversionToHtml(XXX x) in
E:\sitesroot\0\bin.....
Am I overreacting on this? It just seems dumb that it's showing a path on my local. I'm in the midst of tracking down all of the errors of a new Azure deployment, so apologies if this is expected behavior.
Adding in the resolution as answer here.
The pdb files contain additional debug information wrt your binaries. Any failures that show up on a machine with pdbs deployed will show a richer stack information referring back to the source code files with line numbers etc. Deleting out the pdbs will resolve your issue. Plus you ideally should not be deploying pdbs with your retail product bits unless you are actively debugging something in production.
Related
I am attempting to publish my website to a intranet file server, but for some unknown reason a portion of the application seems to be referencing an old version of a class object. The class initializer is throwing an error stating that a stored procedure cannot be found. I know this is old code because that stored procedure no longer exists.
The error:
Could not find stored procedure 'stp_EMS_BM_EmployeeMovements'.
Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.
Exception Details: System.Data.SqlClient.SqlException: Could not find
stored procedure 'stp_EMS_BM_EmployeeMovements'.
The web application runs perfectly on my local machine. I am currently publishing to the file server using Visual Studio 2015 Enterprise.
I have manually deleted all the files on the file server, rebuilt and published the project numerous times. Any recommendations on what to try next would be incredibly helpful.
It appears that some dependency was not fully updated on your website as it had been on your local server. To find what is different, here are two suggestions.
1) Use WinDiff on all your files, including .dll & .exe files. Some old files could have received a new modification date without being modified. WinDiff should show what files are different in these two environments.
2) Compare the file version numbers of like files in the two environments. If the file version was revised with your latest changes, this too will show what files are different in these two environments.
When trying to build a solution I've recently downloaded from source control (TFS in this case), I'm having all sorts of issues which other developers are not.
Sometimes, the project will build. Other times, it will not.
In general, I'm unable to make any source code changes, because as soon as I do, all the web & service references in the project appear to be broken. Re-adding the references does not fix the issue.
The service reference errors will appear as "The type or namespace could not be found..", while at other times I will randomly get "Could not load file or assembly..".
What is going on here? It doesn't appear to be project configuration related.
In this case, the overarching problem was Impersonation. The impersonation account was trying to access many local files during the build, which was surprising to me.
You can check if impersonation is used in a project/site by checking the web.config (that is used in your development mode - if you use web.config transformations check your Debug/Release configuration) for:
<identity impersonate="true" userName="XXXX" password="XXXX"/>
If impersonation is enabled, the impersonation account will need various access on your local machine.
In my case, the impersonation account needed full control to the following locations:
C:\Users\MYUSERNAME\Documents\IISExpress\
DRIVE:\SourceControlProjectLocation\
C:\Windows\Microsoft.NET\Framework
C:\Windows\Microsoft.NET\Framework64
C:\Windows\Microsoft.NET\Framework\VERSION
C:\Windows\Microsoft.NET\Framework64\VERSION
C:\Windows\Microsoft.NET\Framework\VERSION\Temporary ASP.NET Files
C:\Windows\Microsoft.NET\Framework64\VERSION\Temporary ASP.NET Files
This was a real pain because because inheritance was broken by default in many of these locations by Windows itself.
Windows 8, VS2013 IIS8,5
I'm trying to connect to a local WEB API by connecting to processes w3pv.exe (Managed (v4.0.30319), 19). The website front end and back end is both running fine on my local IIS. Right after publishing my x86 web API to the local IIS i try to connect to the process, where the break point states "The Breakpoints will not currently be hit. No symbols where loaded for this document". My colleague' can without any problems debug from his local computer.
So far I have.
Reinstalled VS2013.
Checked All Debug Properties
-Project -> build: Define DEBUG constant check / Define TRACE constant check.
Generate serialization assembly = Auto. Advanced build settings -> Debug info = full
Enable Just My Code: Check, Use Managed Compatibility Mode: Check
Enable Edit and Continue : Check
Made sure all Debug mode is set and all project Configured to Active solution platform x86, marked Debug and Build.
Deleted all bin and obj folders, as well as pdb folder in C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files
Reset IIS.
Set Select Code Type to Automatically determine the type of code to debug
Checked in IIS that .Net compilation -> Debug and Enable Prefetch is set to true.
And I still get the same error message. Anyone found anything in addition to this?
I have encountered similar problems many times while training new employees in our very complicated devenv, so here is our internal step by step instruction:
Don't panic
Make sure you attached the debugger to the correct process - you debug the plugin by launching VMS which is external app that has separate config file where the plugin path is stored, so when you change just your configuration Debug/Release it doesn't work.
Make sure you have symbols generated for the assembly Project properties->Build->Advanced->Output section
Make sure the build path hasn't changed. You may have accidentally changed the path and you may only think that the assembly you are trying to debug is the correct one.
Investigating the information you provided this is only help I can think of. My guess is the files you publish are not the files you're debugging locally.
RESOLVED (embarrassed)
A few day's ago, I downloaded the front-end code for the website from the VPN (GIT). I forgot to update the code-behind reference in the App.js file in the front end root. This, of course, referred to the API on the cloud, and not my local API.
This took me way to long to find out. But, at the same time, it's not a solution I've seen so far on the web.
Thanks for all your help.
I am in charge of a desktop WPF application, using a few web services (via Service References of the project).
Due to a Cannot execute a program. The command being executed was \"C:\\WINDOWS\\Microsoft.NET\\Framework\\v2.0.50727\\csc.exe\" /noconfig /fullpaths #"C:\Documents and Settings\admin\Ustawienia lokalne\Temp\btucqeci.cmdline" error on a client's machine (which I understand is caused by csc trying to compile objects for the webservice request on the fly, and failing due to insufficient permissions), I hoped I could use a solution that I came across somewhere and enable the Generate serialization assembly option in the Build / Properties tab of my project.
It won't build, though - I keep on getting a compile error Could not find file 'E:\xxxx\xxxx\obj\Debug\xxxx.XmlSerializers.dll. Well I know it's not there, creating this DLL is precisely what I'm trying to achieve.
All the code for communicating with web-services is auto-generated and I haven't modified it at all.
I tried using sgen to achieve the same result "manually", but with no luck: I'm getting Unable to load one or more of the requested types. Retrieve the LoaderExceptions property for more information.
Could you point me in right direction? If additional information is needed, I will supply it. It's the first time I ran into this type of issue, so I'm a bit in the dark.
By the way, I have a (remote) access to the client's computer, but I failed to resolve the problem by resetting permissions. They run the program on an admin account and permissions do not seem to restricted in any way (based on what I googled up, including this question, I suspected the infamous IIS lockdown effect).
When an exception occurs with any ASP.NET project (possibly any .net app) the stack trace will show the path on the developer's machine, even when in production.
How to change it?
What's going on under the hood?
This information is stored inside the .PDB files that were generated during the compilation of the source code. They contain the debugging information. But normally people don't compile applications on their machines before shipping them into production. They use continuous integration and build servers that are dedicated for this purpose.
Now if you want to turn off debugging details you could configure the level of verbosity and debug info in the properties of your project.
In order to remove it, go to Properties -> Package/Publish Web:
Make sure to click or check the "Exclude generated debug symbols".
This will Publish your site without PDB files attached on the Bin folder. Make sure you are on Release mode before publishing your site for Live environment. One of the main difference of publishing your site without PDB files is that you cannot see the line number on the StackTrace when an error happens on your site.