Didn't realize how drastically setting SQL connections changed from .Net v2 to .Net v3.5 and above.
Any old connections you have that were kept under 'appSettings' in web.config need to be moved to 'connectionStrings' and reformatted.
The way you then set those connections in your code-behind also must be changed.
This page has a great explanation of this:
http://www.connectionstrings.com/store-connection-string-in-webconfig/
Monday, September 23, 2013
See Session Variable Values in Visual Studio Breakpoints
Some developers aren't aware, or forget, how to see the breakpoint values of Session variables while debugging. Sometimes Visual Studio can test your breaking point in order to use breakpoints.
Mouse over the variable and the icon for a drop menu will appear.
Under 'Session', go to 'Keys'.
Under that, go to '_coll'.
Then open either '_entriesArray', if you know the variable's subscript, or '_entriesTable' to scroll through the variable names.
Open the subscript/name to find the key/value settings and click on the value.
If anyone knows how to bypass all this hoop jumping to get this info, I'd be much obliged.
Mouse over the variable and the icon for a drop menu will appear.
Under 'Session', go to 'Keys'.
Under that, go to '_coll'.
Then open either '_entriesArray', if you know the variable's subscript, or '_entriesTable' to scroll through the variable names.
Open the subscript/name to find the key/value settings and click on the value.
If anyone knows how to bypass all this hoop jumping to get this info, I'd be much obliged.
Confounded Configurations
If you maintain different build configurations in Visual Studio .Net projects/websites, make sure you know which one is set as the active configuration whenever you go to do a debug run or publishing.
Always check Configuration Manager under the 'Build' menu before proceeding and change the Active solution configuration as needed.
Mine usually differ only in the SQL connections, each config having its own lil' ole mini web.config file (eg: Web.Release.config) for swapping the standard web.config connections with those needed by the specific configuration.
Always check Configuration Manager under the 'Build' menu before proceeding and change the Active solution configuration as needed.
Mine usually differ only in the SQL connections, each config having its own lil' ole mini web.config file (eg: Web.Release.config) for swapping the standard web.config connections with those needed by the specific configuration.
Great Page Explaining Stored Procedure Speed Issues
Had an issue with an SQL Server stored procedure running far slower than the same
code as a stand alone query.
It was running a totally different execution plan due to the
parameters.
This page explains how all that happens. The key to my issue
was in the section ‘The Default Settings’Pouring through the execution plans for procs can be an eye opener. I've found myself vastly improving performances with seemingly minor changes, such as reordering the join elements, adding indexes if missing on join columns, and in one case, using 'Forceseek' to stop the server from using a particular index and instead use a different one.
Just be aware that a new index that makes your current proc zoom, could adversely affect another proc using that table.
Ah Ha Moment of the Day - Where's This Master Page Coming From?
I'm obviously not a certifiable Visual Studio Guru yet. Ran into a situation many other Dot Net Developers may have, and not even realized it.
I had to revised a couple of Webform pages, moving something from one to the other. Seemingly a simple enough task.
Everything was fine until I did a local publish before submitting for deployment to Stage.
Unlike my local debug build, which produced no errors, this publish generated javascript errors on one page. Since I hadn't changed one single character on any JS or jquery code, I was at a loss.
The offending code was jquery and I feared a conflict maybe between it's dollar symbol and that used in the Telerik library, but ruled that out since no other page, all including both libraries, was generating this error.
At that point I started combing through my source codes and that from the browser, and poured through the master file included in the opening content page tag. I found some archaic 'script src' tags in the offending page that I thought perhaps should be in the master file instead. For all I knew, maybe one of my changes to the form structure was causing something to be read or executed in a different order than previous.
So I start shifting tags from content page to master, rebuild and WTF????????
Nothing I added to the master page was in the new content page source code!!!
I finally discovered, upon going through the various master page files, that despite the master page referenced in the content page, a totally different master page was being used. I confirmed this was the case after making tiny revisions in both and seeing the second master was definitely the one included in the build.
In the end, I fixed the jquery error by including a library script that I saw was in the other content page, which also had the same jquery method and wasn't throwing the error. Whatever the reason why my local debug build didn't throw the error, I wasn't about to fight with the Stage build to find out why. I gave it want it apparently wanted, returned the master pages to their original state, error gone.
BUT, I still wanted to know how the hell was the hard coded master page being swapped out and by what setting, or process? I'd already gone back and forth through all the Visual Studio menus I figured might be doing this via some project level setting.
Finally I discovered that Global.asax.cs was overriding the hard coded master with the second one. Learn something new every day. Had never considered that prior. Makes perfect sense if you don't want to risk globally changing the opening tag of every page on your site.
I had to revised a couple of Webform pages, moving something from one to the other. Seemingly a simple enough task.
Everything was fine until I did a local publish before submitting for deployment to Stage.
Unlike my local debug build, which produced no errors, this publish generated javascript errors on one page. Since I hadn't changed one single character on any JS or jquery code, I was at a loss.
The offending code was jquery and I feared a conflict maybe between it's dollar symbol and that used in the Telerik library, but ruled that out since no other page, all including both libraries, was generating this error.
At that point I started combing through my source codes and that from the browser, and poured through the master file included in the opening content page tag. I found some archaic 'script src' tags in the offending page that I thought perhaps should be in the master file instead. For all I knew, maybe one of my changes to the form structure was causing something to be read or executed in a different order than previous.
So I start shifting tags from content page to master, rebuild and WTF????????
Nothing I added to the master page was in the new content page source code!!!
I finally discovered, upon going through the various master page files, that despite the master page referenced in the content page, a totally different master page was being used. I confirmed this was the case after making tiny revisions in both and seeing the second master was definitely the one included in the build.
In the end, I fixed the jquery error by including a library script that I saw was in the other content page, which also had the same jquery method and wasn't throwing the error. Whatever the reason why my local debug build didn't throw the error, I wasn't about to fight with the Stage build to find out why. I gave it want it apparently wanted, returned the master pages to their original state, error gone.
BUT, I still wanted to know how the hell was the hard coded master page being swapped out and by what setting, or process? I'd already gone back and forth through all the Visual Studio menus I figured might be doing this via some project level setting.
Finally I discovered that Global.asax.cs was overriding the hard coded master with the second one. Learn something new every day. Had never considered that prior. Makes perfect sense if you don't want to risk globally changing the opening tag of every page on your site.
Subscribe to:
Posts (Atom)