Showing posts with label debugging. Show all posts
Showing posts with label debugging. Show all posts

Wednesday, August 26, 2009

Developer AutoLogin & Redirect

A large project I'm working on these days includes a Login page which each user must pass through before being able to access the rest of the site. There is code similar to this that prevents unauthorized entry onto every page:












For some time I would just comment out this code until the rest of the module was complete. The problem with that is that as the application became more & more sophisticated, there was assorted initialization code elsewhere that has to be executed each & every time.

For the Run-Debug cycle it became exceptionally time consuming (and annoying) to manually go through the entire login process every time. Here's an example of the steps involved:







































Oh sure, it's just a few keystrokes and mouse clicks each time but repeated dozens (or hundreds!) of times per day, one soon hopes for a way to automate the process. And I found it!



In Visual Studio's Solution Explorer, right-click on whatever page you're working on and choose "Set As Start Page" from the popup menu. Note: You've probably already done this!

Now in the Page_Init event handler of your Master Page (FYI all my projects use Master Pages) add this code:

protected void Page_Init(object sender, EventArgs e)
{
if (!IsPostBack)
{
// If we're on a development machine then record the Start Page that Visual Studio is set to
string currPage = Page.ResolveUrl(Request.ServerVariables["URL"].ToString());
if (System.Diagnostics.Debugger.IsAttached && SessionData.GetCurrentUser() == "")
if (SessionData.GetSessionObject("CurrentDebugPage") == null)
SessionData.SaveSessionObject("CurrentDebugPage", currPage);
}
}

Then in the Page_Load event handler of your login page add this code:

// Note: This must be set above: using System.Web.Security;
protected void Page_Load(object sender, EventArgs e)
{
// This tests whether we're running on a development machine. If so, we'll automatically login.
if (System.Diagnostics.Debugger.IsAttached && SessionData.GetCurrentUser() == "")
{
string currUser = "your_username";

FormsAuthenticationTicket ticket = new FormsAuthenticationTicket(currUser, false, 5);
string encryptedTicket = FormsAuthentication.Encrypt(ticket);
HttpCookie authCookie = new HttpCookie(FormsAuthentication.FormsCookieName, encryptedTicket);
Response.Cookies.Add(authCookie);

// If a specific page has been set as the Start Page then redirect to it; otherwise go to the Default page
string currDebugPage = SessionData.GetSessionObject("CurrentDebugPage").ToString();
HttpContext.Current.Response.Redirect((currDebugPage == null) ? "~/default.aspx" : currDebugPage, true);
}
}

Note: The various SessionData methods are just simple ones I've constructed to ease the process of storing & retrieving variables in the Session State. I will gladly provide them upon request.



The result is that now, every time I run my project in Visual Studio, it jumps right to the desired web page, logging me in automatically. And yet when run in non-Debug mode it works normally. So I don't have to alter any code whenever I release a new production version.

In case you're wondering how this works, the process is quite straightforward:
  1. The Master page's Page_Init event handler is run before every Content page's Page_Load event handler. It records the start page that the developer wanted to go to, placing this string into a Session variable.
  2. When that desired page's Page_Load event handler is initially entered, the security checks therein reject entry because the user is not logged in. They then redirect to the Login page.
  3. In the Login page the special test in Page_Load passes because the code is being run from Visual Studio and because the user is not yet logged in.
  4. A FormsAuthenticationTicket is instantiated and then placed in a Cookie. This allows one to artificially login through the ASP.Net Login mechanism.
  5. The desired start page, originally stored by the Master Page, is retrieved from the Session State and control is redirected to that page.
  6. This second time the security checks in the desired page's Page_Load event handler pass because the user is now officially logged in.
It actually works really well and will save you a lot of time! If you have any questions, please just leave a comment.

Monday, April 27, 2009

Using Fiddler with Visual Studio 2008

Fiddler is a great tool but when I tried to use it to monitor a Visual Studio 2008 web app running locally on my Vista 64-bit computer, it did not work.

I searched around some and finally found this blog posting. Within the comments a fellow suggested changing the URL to this syntax:

http://ipv4.fiddler:1234/MyApp...

I assume this is intercepting traffic in between Fiddler and VS2008. Whatever the case, it works!

Wednesday, April 22, 2009

Upgrading Crystal Reports Files from VS2005 to VS2008

I just upgraded a fairly large project from Visual Studio 2005 to 2008. Everything went fairly smoothly but I did encounter hundreds of errors when I got around to upgrading the Crystal Reports data files.

In VS2005 I have a pair of files for each report:
  • ReportName.rpt
  • ReportName.xsd
where "ReportName" changes accordingly.

In VS2008, when you bring an XSD file into a project it creates 3 other files:
  • ReportName.Designer.cs
  • ReportName.xsc
  • ReportName.xss
I didn't know the purpose of this trio but assumed they were necessary in VS2008.

In point of fact, all the conflicts occured within the ".Designer.cs" files. There are global variables in each one that cause repeat definitions of the same variables, which is not allowed.

So I did a little research and came across this blog entry. I ended up following just the first part, which was to delete the ".Designer.cs" and ".xss" files. Plus, because all the ".xsc" files were empty, I deleted them too.

Lo and behold, I rebuilt the solution but these excess files were never recreated. More importantly, the reports worked perfectly once again!



Update: One problem I've discovered with the above procedure is that you still end up with one warning message per report like this:

The custom tool 'MSDataSetGenerator' failed while processing the file 'Reports\Templates\MTHOBRK3.xsd'.

The application still runs but I don't like any such warning messages to be present. After a little trial & error I found this to be the ultimate solution:
  1. Delete the .xsc & .xss files only.
  2. Replace the entire contents of each .Designer.cs file with the following:
#pragma warning disable 1591

namespace Website.Reports.Templates
{
public partial class NewDataSet
{
}
}

#pragma warning restore 1591

Monday, December 1, 2008

Customizing a Breakpoint in the VStudio IDE

If you're like me, then you frequently setup breakpoints throughout your code to assist you with debugging. Today I had a unique situation where I wanted the code to stop only when a variable acquired a specific value. I looked around the Visual Studio menus but couldn't see anything to help me. So I posted this on an ASP.Net forum. Sure enough, within a few hours a fellow responded, pointing out that one could right-click on a breakpoint and customize it in several different ways. I had absolutely no idea of this! Here are some screenshots:



Monday, April 21, 2008

Debugging with Visual Studio 2005 in Windows Vista

What a Microsoft level headache I encountered this evening. That's my code for, "it should work but it doesn't because of something Microsoft didn't take care of properly".

I wanted to do something similar: Debug a simple ASP.net 2.0 web page in Visual Studio 2005, running on my Windows Vista Ultimate 64-bit machine. I added a Debug.WriteLine statement in the Page_Load event handler of default.aspx.cs and sit it as a breakpoint - as I'd done thousands of times before with Windows XP.

I pressed F5 and looked at the code screen, naturally expecting the app to stop on the designated line. And . . . it didn't! I tried again, but still no go. So I shut down VS2005 and cleared all the DLL files from the bin folder and all the files from the obj folder. I restarted it, recompiled, and tried again. Still didn't stop!

Then I did a ton of research and via Scott Gu's [excellent] blog was taken to this page. There are a LOT of steps. After following the instructions in the last one I tried again but it still didn't work! So then I examined this series of articles by Mike Volodarsky. I followed the VS2005 link and carefully went through the steps needed to get debugging working. I didn't actually go as far as running the app through IIS7 as I intuitively couldn't believe that the internal web server in VS2005 wouldn't debug properly in Vista.

I did some more research and came across this ASP.net forum posting. Note that the second fellow, from Lahore, Pakistan insisted to check the web.config file and be sure that debug is enabled. "Of course it must be", I thought. But when I checked, it was not! So I changed it to:



I hit F5 again and ... it worked!! I don't know for sure whether all those other steps were necessary though I think that installing the hotfix was probably a good idea.

In conclusion, I must say that situations like this are all too common with Microsoft development products. This should have been a "5 minute" thing to fix, but I wasted 90 minutes of my time on it. I simply don't accept that such things should be happening from a paid for product built by a multi-billion dollar company.

Though with the introduction of this blog, I hope to help others save countless time in the future by documenting situations like this and having it picked up shortly by the search engines.