We have several ASP.NET applications that use a sitemap which is populated via a VB.NET implementation of the SqlSiteMapProvider example found at Wicked Code. It is compiled to a DLL, then installed and referenced from the GAC on the servers and from our locals as well. It has been working in production just fine for a few months now. I should also note we are using SQL Server 2008
Today we came in and noticed in production that there was no menu items being displayed at all on the sitemap in prod for any of the applications. Dev & QA looked fine. We have not done any maintenence to SQL Server in prod in quite some time, long before we ever even implemented SQLSiteMapProvider. We also have no updated any of the web apps recently.
The first thing I did was take the prod web.config and set it to my web.config in my IDE and run the app - still the same issue. This should rule out an IIS issue since the bug was replicated on my machine as well.
Since this was a bit urgent, the next thing I did was simply insert a dummy record into the sitemap table in prod to see what would happen. Poof, like magic, the menu items were restored and all was well. I deleted out the dummy menu item and it synced without issue.
This was a bit scary though, and I'm trying to figure out why this happened so that it does not happen again in the future. Has anyone experienced this before? If you have never used SqlSiteMapProvider - it simply uses SqlDependencyCache/ ASP.NET cache to store the menu items, then if the result set of the stored proc which returns the links changes, it tells ASP.NET this happened and it re-populates the sitemap/cache...
Maybe the connection between the web server & SQL Server somehow died? And inserting a record made it 'wake up' and reconnect again? Maybe there is a timeout value or some kind of IsStillConnected() function somewhere I need to check on PageLoad to make sure the connection is still in-tact? Or maybe ASP.NET thought the stored proc was returning no values for some reason until we inserted a record into the table? Has anyone seen this issue before?
Many thanks in advance for any guidance.
EDIT: all this came from having a SET NOCOUNT ON in my stored proc. BEWARE! This is not in the MSDN docs anywhere and really screwed me for awhile!
SqlDependency is not exactly a powerhouse of stability. Here are some articles that perhaps can shed some light:
The Mysterious Notification
SqlDependency.OnChange callback timing
When it rains, it pours
Check my edit ;)
all this came from having a SET NOCOUNT ON in my stored proc. BEWARE! This is not in the MSDN docs anywhere and really screwed me for awhile!
Related
I have a WebAPI that I am able to debug/deploy in 4 different place with no code changes and it only acts different in production. On the image below, the left shows the local dev machine (both VS & IIS), the right shows the production server, both IIS, one for staging one from prod. It started out as a CORS issue I thought...I could tell headers weren't being sent and received. But as I'm digging in, I can see it starts before that. It's saying that the ClientId is not being sent (AzureAd), although it's obviously working fine on other 3 environment scenarios.
Then I used chrome://net-export/ I found in this question. As I dug in through the results of that, I went all the way to just before stopping the logging, when the error is shown and I can see that the ClientId IS BEING SENT (second image shows cleaned up from the net export file). An Access Token is being sent back as well
Response being returned
Both the request and response show up as a socket connection. I don't know enough about that to know if, or what, impact that may have
So, I've been struggling on this and am now at a complete loss. The staging and production are same server. This isn't a new production site; it's actually been up for over a year and working fine. It's managed code, running on IIS on Win 12 Server.
Here's the differences: This is after .net core upgrade. Again, works everywhere else, even on same server.
ANY IDEAS at all before I go completely bald????
UPDATE: I finally fixed this. In the web.config, I changed the ASPNETCORE_ENVIRONMENT value and it began working immediately.
This is one of those issues that are not too usual, but maybe helpful to someone in the future. The Web.Config never crossed my mind through all of this. This was simply matter of desperation at this point. I swear sometimes just asking the question is the magic. :-)
Several years ago I created an asp.net web page with VB2010 that runs on our company's web server. It has been running with an Ajax script manager and an Ajax update panel. It has been working fine for years.
Today when I needed to make a change in the code, the IDE is suddenly showing errors not recognizing the script manager or the update panel. (Edit for clarification: The errors showed up before I even made any changes to the code.)
For a test, I added an Ajax timer to the page, and the IDE flags that as unrecognized also.
All of the answers I have found online, including here, refer to making changes to the aspx code or to the web.config file, but I am hesitant to do that because it has been working fine all this time without needing those changes.
To my knowledge, nothing has changed since the last time I made changes to the application. It sounds like something may have been corrupted, but I have no idea where to look.
Does anyone have any ideas?
Thanks!
We recently migrated from VS 2008 to VS 2010. The migration went fine, except for our web project. Before, in VS 2008, the site showed up as http://localhost/Website. Now, it appears as C:...\Website. It appears that when we did the migration, VS started to treat it as a file system website.
I've tried removing the existing site and re-adding it as an existing website, but it still displays it as C:...\Website. Is there any way to convert it back to show it as a http://localhost/website, and run through IIS, as opposed to the default ASP.NET Development Server?
Special thanks to John Dundon at Microsoft for helping me resolve the issue. Here's what he said:
Thanks for all the details. This actually sounds like a quirky behavior
in VS that I think I can help you work
around.
I believe the reason it’s remembering
to use the local development server is
because it got stored in the SUO file.
So there are two possible ways to fix
this:
Re-open your solution from source control as an administrator on the
machine with IIS installed and
everything should get downloaded to
its right place
If you close VS, delete the SUO file (note – this will erase some
settings about the state of your
solution but shouldn’t cause any real
data loss), and then re-open the
solution, it should ask you to
re-download that particular web site
and will try to make it an IIS web
site again.
Note however though that since your
virtual directory already exists on
your machine, it’s going to ask you if
you want to use it – I’m assuming you
do, but it will overwrite any files
when it does.
Let me know if this works for you (and
while you technically shouldn’t need
to, it may be a good idea to back up
any work you’ve done in this
enlistment that hasn’t been checked in
prior to trying this).
I followed his advice and removed my SUO file and re-opened the solution. The website was automatically fixed as http://localhost/Website and it also checked out the .SLN file as well, and when I checked it in, it fixed the issue for other developers as well. Hope this solution helps out others as well with this quirky issue.
Look in the project properties, on the Web tab. You'll be able to select whether to use IIS or the development server, and which virtual directory to use.
I have three Silverlight 3 applications in the same solution. In my asp.net hosting project I have a seperate page for all three projects. When I navigate between the pages, the only Silverlight breakpoints that get hit are the ones the initial page I load.
This problem has only started recently. I used to be able to debug between all silverlight projects at the same time. Any ideas? I have deleted the ClientBin folder, I have deleted all files and re-retrieved from source control. Nothing seems to be working.
"The problem has only started recently". What changed? Here are some guesses:-
You upgraded to Windows 7
You installed some more memory
Some other memory guzzling app is no longer running when you are testing.
By default IE8 will run multiple processes at least 2. One for the browser frame and one for the content of the intial tab. As you open more windows and tabs IE may add new processes to the set it is currently using.
When you debug VS will launch an new IE8 session and will attach to the process handling the content of the single tab that is open, (it doesn't bother attaching to the parent frame process). However as you navigate about your application IE8 will start new process that VS won't be attached to. This forces you to open the Attach to Process dialog and do it manually.
You can control this IE8 feature (called BTW LCIE, Loosely Coupled IE) from the Registry.
In the Key HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\Main add a new DWORD value TabProcGrowth. Set its value to 1. Now IE8 will only ever create 2 processes per session one for the frame and one for all the tab and window contents which is the one the VS will attach to.
This perhaps is a bit draconian if you also use IE8 as your general browser. One option is to leave IE8 for test purposes and use another browser for general browsing. Another option is a variation of the above. Instead of creating TabProcGrowth as a DWORD create it as a string type instead and set is value to "small". In this mode IE8 is much less aggressive in the number of processes it will open. Of course you could create a couple of scripts to create and delete the registry entry.
Note without the registry entry IE8 uses its own hueristics that depends on available memory etc to determine if a new process is warrented or not. This might explain why in the past your debugging worked and that for apparently no reason it stopped working.
Here was the issue:
One of my child windows had a Silverlight that calling a .Net Ria Service. The service call ended in an error.
The next time several I debugged, the debugger did not attach to the child windows. I had to attach to the child windows manually.
I fixed the Ria Service call so that it did not end in an error. And had to manually attach to the child windows in that debugging session. However in subsequent debugging sessions, the debugger automatically attached.
I tried breaking the Ria Service call and I had to manually attache again. What is a little weird is that closing Visual Studio and even rebooting the machine does not make Visual Studio automatically attach again. You have to have a debugging session where the child window make a sucessful call to a Ria Service to fix it.
NOTE:
The RIA error that was breaking my debugger was caused by a misspelled include in the domain query (ie...
return Context.SOME_ENTITY.Include("Misspelled_Association_Property");
) not all RIA exceptions cause this problem.
My scenario has a number of specific cases that I will go over. I don't have all the things handy to test a more general scenario, but I will when I finish my project unless someone does this first.
Here is what I have:
I am using the a LinqToEntitiesDomainService from the July 2009 Preview release of .Net RIA Services.
To complicate things a little more, since my application is using an Oracle backend, I am using DevArt's dotConnect Entities provider as the EntityFramework model for my domain service.
When I get time, I will try this on the Nov 2009 RIA and a standard SQL backend and EF to see if I still have the same issue. If this is the case I will report it to Microsoft as a visual studio bug.
Every now and then when I am running/debugging an ASP.NET MVC website through Visual Studio and if I am changing some CSS or HTML in a View while the project is still running, the Session will drop intermittently.
I have confirmed this in the Global.asax adding a Session_End method and setting a break point inside it. As soon as I click Save All through Visual Studio after about 10 or so minutes Session_End is called. I don't even have to refresh the actual page which I think is a little bizarre...
I realize that recompiling the app would cause the session to be lost, but I would not think modifying a View while the application is running would cause this.
Any thoughts on why this could possibly be happening?
Since you are clicking Save All, is it possible that you've also modified a code file or the web.config as well. Any sort of change -- even if you removed it -- would make the file dirty and cause it to be saved as well. This may cause the behavior you are talking about.
You might want to think about using SQL for session state in your development environment. I recently switched to this (because I needed to for our production environment) and no longer see that sort of behavior even when I stop debugging and recompile the application. As long as the session cookie is still valid, it is able to pull my session information from the database.