Strange Problems
Problems that occur that I have not found much information about.
Ran into a performance issue in a .Net remoting situation. A Winforms app is calling an application server asking for data. A relatively large DataSet (>10,000 rows, <6 columns) being passed over the wire was causing a performance problem. The database and application servers processed it quickly. Examining the transfer with WireShark showed that the transfer wasn't so bad either. There was a flurry of data passed, and then a bunch of waiting on the client-side, with the client CPU usage around 50% the entire duration of the wait. Turns out there is a calculated column in one of the data tables. The column is not calculated on the application server-side, so as not to pass a bunch of data across the wire that would be unnecessary. The calc happens on the client. That was the source of the slowdown and CPU usage. In the end the solution to the problem was not using the calculated column, we found a different solution to fix the business problem. I suppose you could perform the calculation in the SQL statement that was ultimately filling the DataSet. That might take longer to transfer, but won't slow down the client app.
I deployed a site today that has some code in the Global.asax event handlers. I let Visual Studio 2008 add the file to my project when I created it, and it put the code directly in the file inside <script runat="server"> tags. I went with it. So when I deployed the file, none of the events fired. Ever. The lesson is: Don't put your code in the global.asax file. Apparently this problem is by design. There is a vague KB Article on this problem, but the solutions aren't all that helpful, I didn't want to pre-compile, and the first solution made no sense at all. A little searching and I found one good solution: put a class that inherits HttpApplication in the App_Code folder as described here. What I don't understand is why Visual Studio adds the file that way if it isn't going to work on an xcopy deployment. Microsoft seems to go out of their way to protect us from ourselves so often that I am surprised the IDE does something intentionally that won't work.
On a new server install, you can copy over the files for your web app and mysteriously get 404 errors. It's a simple configuration in IIS. By default the server is configured not to allow ASP.NET. You simply need to enable this in the IIS management console:
We had code in an ASP.NET page trying to call the Commerce Server Profiles web service that resides on the same physical box. The credentials we used were appropriately configured for Commerce Server using AzMan. For some reason, the code was failing with a 401: Unauthorized error. No matter what credentials we used, no luck. But if you ran the code from another box, it worked fine. Same credentials pointing to the service on that box, no errors.
Turns out the hosts file had an entry for the DNS name we were using, and mapped that name to 127.0.0.1, the loopback address. This was the gotcha. Apparently there is a loopback security feature that causes this behavior. There is a support article describing the effect. Essentially it is a security check to keep certain kinds of attacks at bay. The article suggests registry changes to disable it, but we took a different route. In the short term, if the calling code accessed the web service via IP address (NOT 127.0.0.1) instead of DNS name the problem was circumvented. Meanwhile the network guru is working to get the actual DNS resolution to work.
I blogged previously about some
issues with SelfSSL and multiple web sites. A colleague of mine,
Charles Medcoff, blogs about a related problem with
SelfSSL and SQL Server.
I kept getting an error when trying to use
CopySourceAsHTML in Visual Studio 2005. The error was that CopySourceAsHTML was unable to access the clipboard. Turns out the problem is when using it in a VPC, and
the answer is here.
OK, now that would seem like a pretty straightforward problem, but really it was something else altogehter.
Currently I am writing a helper app for MCMS (Microsoft Content Management Server) 2002 to migrate files from another CMS to MCMS. I am using C# and PAPI calls. Everything was fine on the development server. When I moved the app to the staging (QA) server to perform the migration there (you can't use PAPI remotely), the app got an exception the moment it tried to connect to MCMS: "The CMS Server license has expired". Of course immediately I thought the obvious. After a little digging I found this information in the FAQ implying that I didn't have the proper permissions. I had the server admin elevate my permissions and immediately the problem was solved.
The lesson here: "Develop with least privledges!" It will save you headaches later.
With extensive use of the ListObject in an Excel VSTO project, I have identified a
second actual bug in the ListObject. This one also has to do with pasting data like the
previous bug I posted about, but this time data is being lost instead of created erroneously.
My copy of MSDN magazine arrived last night, and I read the article Practical Tips For Boosting The Performance Of Windows Forms Apps. Good read. Anyway, I was shocked to find out that I have been databinding lists improperly ever since I have been using .Net. I frequently wrote my code like this:
//Bad Code
combobox.DataSource = datatable;
combobox.DisplayMember = "State";
combobox.ValueMember = "Id";
//Good Code
combobox.DisplayMember = "State";
combobox.ValueMember = "Id";
combobox.DataSource = datatable;
Apparenly, order matters very much. In the first example, the combobox binds using the DisplayMember, then rebinds when updated with the ValueMember. In the second example, the binding only happens once.
In our current app, we have two lists that contain thousands of items that need to be bound, so we are binding them during the startup process so the user won't wait when requesting that data. The startup time was reduced by just under 40% by changing the order of the code for binding.
I found an actual bug with the VSTO ListObject in Excel and insertions of data. See
this post on the MSDN forums for details.
SelfSSL is a tool found in the IIS 6.0 Resource Kit. It allows you to generate SSL certificates for a development environment. In all the instructions for using SelfSSL, it describes one of the parameters as "Site ID", where the default value=1, which is the default web site installed on the computer. The Site Id parameter is essentially telling SelfSSL which web site to install the certificate into. Well, if you have multiple web sites, then the default site id is useless. You need the Site Id of the web site where you want the certificate installed. Of course the documentation does not spell this out, and as a non-Admin the Site Id was not an intuitive term for me. But I found that there is a script you can run from the command-line called iisweb.vbs using the /query switch. That will tell you the Site Id. Seeing that, then I realized that the IIS log file folders (in windir\System32\logfiles\) are named according to the Site Id.
Anyway, creating a second certificate for a different site on the same IIS using SelfSSL messes up the SSL cert of first site. This is a known issue apparently, and David Wang has a great post on this problem. The comment further down by Paul Carrig is most useful, as he points out there is a workaround for the SelfSSL and multiple site issue. So I actually found two workarounds:
- The technique described by in the aforementioned post:
- Install the cert in the first site
- Export it to a .pfx file
- Install the cert in the second site
- Remove the cert from the first site
- Re-Import the cert to the first site using the .pfx file
or
- Install the cert in the first site, and export it to a .pfx file. Then import that to the other sites. The down side to this is that the certificate is even less valid for the second sites as now it has an untrusted publisher (me!) and the site name is not a match. The prompt is essentially the same, but in our case one site contains web services which will throw an error if the prompt comes up at all (as it should). The workaround for that is to install the certificate on the client computers as well, which is an acceptable problem for a development enviroment.
Today we are migrating my project from Whidbey Beta1 to Beta 2 (if you know why this is happening today, go ahead and laugh with us), and our biggest hurdle so far is Typed Datasets.
We used dozens of XSD schemas to create typed datasets. Of course, Beta 2 no longer gives a menu option for creating a typed dataset directly from a schema (see this post in the Fedback Center for Visual Studio). The prospect of converting to the Dataset type of schema was daunting, and moving to the command line for xsd.exe was not going over so well either.
We did discover, however, that you can still generate the dataset using the IDE. In the properties of the XSD file, you can set the custom tool to MSDataSetGenerator. Then you can right-click the XSD file and choose Run Custom Tool. The IDE generates the code for the dataset. Whew!
We have been using Virtual PCs to host a separate development environment. Some of the team members have been having sporadic network issues with SourceSafe on the Virtual PCs. They were unable to get all of the projects involved down to the Virtual PC without getting a “Network Not Found” error. Eventually they would get all the files, but it was clearly not the best situation.
The Virtual PC image was sysprepped before distributing it, to avoid network problems. Unfortunately, that is not completely the case. Sysprep does reset the MAC address on the Virtual PC, but it apparently happens when sysprep runs, not when the user is re-setting up the PC. After distributing the image, the subsequent users still had the same MAC address. This was causing network problems when more than one person were using the Virtual PCs at the same time. The problem manifested itself mostly with SourceSafe, especially when there was a large change and multiple users were getting all the latest files at the same time.
At least the solution was simple once we realized that the MAC address was the issue (thanks to an astute network admin who had noticed some problems with a particular MAC address on one of the switches). In the .vpc file (it's XML), there is an entry for ethernet address. It contains the MAC address the Virtual PC uses. If you remove the data from the tag, leaving the empty tags, Virtual PC will auto-generate a new MAC address the next time it starts up. Since that change the “Network not Found” error has disappeared.
Mark Brown posted his fix for a bug in the FillDataSet method of the SqlHelper in the Data Access Application Block. The problem occurs when trying to use the FillDataSet method to fill a typed dataset that contains more than two tables. It works great for the first two, not at all for the subsequent tables.
I gave Marks\'s fix a try, but it still didn't fix the problem for me. I did more digging and found a slightly different fix straight from the authors of the DAAB on the GotDotNet workspace for the DAAB. The fix is in the bug section (direct links don't seem to work) This cleared up my problem right away. Of course, the bug is fixed in version 3+ of the DAAB. If you are like me, the MSDN site has been my source for the code for the application blocks, and of course there is only 2.0 on the site.
I did not realize they were on version 3 of the DAAB. The authors have added support for an abastract factory to make the SqlHelper ADO.Net provider independant. I don't know about the rest of you, but the only projects I have ever had to change the database provider on have been Access upgrades. I have never had to move a database back end, say from SqlServer to Oracle. Is it more common than I realize?
After a harried development and delivery of a good sized Software Spec document to a client before the holidays, I have tried again to load XP SP2 on my laptop (hp compaq nx5000) without success. Despite updating all the drivers and the ROM before loading SP2, I still get blue screens after the profile loads, but not every time. The plan now is to wipe it out and start from scratch.
I applied the .Net Service Pack 1 to a Windows 2003 server last night and the web application served from it stopped submitting postbacks. When the login page was sent to the client (IE 6 on XP, 98, and 2003 that's all I had to test with at the time), the javascript was preventing the postback from the submit button. The validators all worked, but the page just would not post back. Click the button...nothing. The development machine with XP Pro and the Service Pack 1 did not have the same problems. I ended up rolling back the patch to get things working as it was late and I didn't find any solutions right away, but this morining I found some other possible workarounds.
There is a discussion of the problem and several potential solutions on the Channel 9 site.
I tried to install the SharePoint web part templates today and got this error:
"Visual Studio .NET must be installed before you can install the Web Part Templates for Visual Studio .NET."
But of course, Visual Studio is installed. I found two answers to the problem on the Usenet:
Add Missing Registry Keys
Reinstall Visual Studio
Along the way I also discovered that you must either have the Microsoft.SharePoint.dll on your machine or on a share you can access in order for the install to proceed.
The public site I maintain is gathering 500 errors of the dreaded “The viewstate is invalid for this page and might be corrupted” type. Strangely enough, the only users seeing this error are Macintosh users, using IE! The problem is not isloated to a single page, it seems to be happening on any page, but not necessarily every page for that user. In some cases it is clear that the user was getting around fine (they were logged in as members to the site), and later the problem occurred.
I cannot find anything on the web except a solitary Usenet post of a person describing the exact same problem.
Here are the agent strings of the browsers recorded when the error occurred:
Mozilla/4.0 (compatible; MSIE 5.0; Mac_PowerPC)
Mozilla/4.0 (compatible; MSIE 5.17; Mac_PowerPC)
Mozilla/4.0 (compatible; MSIE 5.15; Mac_PowerPC)
Mozilla/4.0 (compatible; MSIE 5.16; Mac_PowerPC)
According to the log files, MacPPC users are just under 1% of the site users, so this problem is clearly not a showstopper, but I hate for any users to have a problem. I am hoping to get a Mac set up to test the problem locally, but the agent string doesn't give me any Mac OS versions....
An ASP.Net site we created is having infrequent problems with logins using forms authentication. Essentially what happens is that the user attempts to login and is successful, but then is redirected back to the login page immediately. So it looks like an infinite loop of logins. We have been able to deduce that the cookie is related to the problem. If the user deletes their cookies in IE the problem goes away. The problem is very intermittent, so it is very difficult to reproduce. It is not generating 500 errors or errors in the logs. From extensive Googling, the best I can come up with is the fact that we allowed the cookie to persist across sessions, and the problem is related to that. So I changed the createPersistentCookie parameter to false:
FormsAuthentication.SetAuthCookie(nResult.ToString, False)
Of course, solving the problem is only a wait-and-see in this case, since I can't reproduce the problem directly. I thought our login code was pretty straightforward, letting ASP.Net do as much of the work as possible.
Imports System.Web.Security.FormsAuthentication
....
....
'txtEmail, txtPassword are textboxes on the form, lblMessage is a label control
Public Sub Login_Click(ByVal snd As System.Object, ByVal e As System.EventArgs) _
Handles LoginButton.Click
Dim NotRegistered As String = " is not a registered email address. “ & _
“Please use the Create A Profile link to register."
Dim nResult As Integer
If Page.IsValid Then
Dim sPassword As String
sPassword = HashPasswordForStoringInConfigFile(txtPassword.Text, "sha1")
nResult = LoginResult(txtEmail.Text, sPassword) 'Validate against the database
If nResult = -1 Then 'Not a registered user, display error message
lblMessage.Text = txtEmail.Text & NotRegistered
ElseIf nResult = -2 Then 'Bad password, set error message
lblMessage.Text = "The password for " & txtEmail.Text & _
" is incorrect"
ElseIf nResult > 0 Then 'Registered user, nResult is their ID number
If Request.QueryString("ReturnUrl") <> "" Then 'Redirect to requsted page
RedirectFromLoginPage(nResult.ToString, False)
Else 'Go to My Jobs by default
SetAuthCookie(nResult.ToString, False)
Response.Redirect("../MyJobs/My_Jobs.aspx")
End If
End if
End If
End Sub