In SQL Server Integration Services (SSIS), you're trying to import from a data dump from another database system that has different data types from SQL Server. While the conversions look pretty straigh forward, you get failures of the type "The value could not be converted because of a potential loss of data.". But despite the mismatch data types, you can't see anything wrong.
In newly AJAX-enabled .Net 2.0 page, buttons that redirect user to another page are suddenly throwing the following error:
Sys.WebForms.PageRequestManagerParserErrorException: The message received from
the server could not be parsed. Common causes for this error are when the
response is modified by calls to Response.Write(), response filters, HttpModules,
or server trace is enabled. Details: Error parsing near
'<BODY><ASP_SMARTNAV_'.
This article is part of the series An Exercise in Performance Tuning in C#.Net.
As I look at the code I now have, I wonder if the fileLines variable is an
unnecessary intermediate step. Can I rewrite so that stream.ReadLine() is
passed directly into the parsing? If I do so, I'll be leaving the file open
longer, but since no other application should be attempting to access the file,
I'm okay with that. This means moving the open file command into
MyClass.ProcessFile().
This article is part of the series An Exercise in Performance Tuning in C#.Net.
It's time to stop ignoring the 800 pound gorilla in the room: System.String.
Scrolling all the way over in the Allocation Graph, it is clear that strings
take up most of the memory, and it seems logical that most of that comes from
the input file.
(removed link to missing image file)
I don't often have cause to use threading. In fact, I've found that it sometimes gums up the works (perhaps because I don't understand it well enough?) — slows things down. But when I do want to do some threading in C#, here are a few pages I find helpful in reminding myself how to perform various functions:
"Failed to create component" error pops up when dragging a custom
Windows Forms control from the Toolbox onto a form. Offending line: foreach (Attribute att in Assembly.GetEntryAssembly().GetCustomAttributes(true)).
I have started building a custom DLL containing items for re-use between different Windows Forms projects. An obvious candidate is an About window. I created this as a custom control in the DLL project; the control contains a textbox, which I want to fill with the application name, the version, copyright information, and company name. All of this is to come from the AssemblyInfo.cs file, using System.Reflection where necessary:
This article is part of the series An Exercise in Performance Tuning in C#.Net.
At this point I did not re-run the profiler but continued investigating memory allocation. Here's an interesting looking result:
(removed link to missing image file)
in Visual Studio's debugger, you've landed on an Exception statement. You look at the stack trace but it just points back to a custom exception class you've created. But you know that code is good, it can't be throwing the error. What's going on here?
this is an easy mistake to make. I've run it across it in code from a number of people, and recall making the mistake myself at one point. The problem is most likely due to nested throws to a new custom exception.
This is not part of my series on performance tuning a specific app.
I have a Registry class in which I want to place a generic collection of objects. In this way I can add new items to the registry on the fly (i.e. from a user application), without having to recompile the library containing the the class. What is my best option, in terms of performance, for a .Net 2.0 collection to hold my mixed-bag of objects? I'll be referring to these with a string name.
This article is part of the series An Exercise in Performance Tuning in C#.Net.
Where else could I improve performance? I thought I should inspect the memory usage and garbage collection. For that I found a great little tool from Microsoft, the CLR Profiler, which I found through the MSDN Patterns & Practices series of guides on application performance and scalability. The specific article that I found most helpful was How To: Use CLR Profiler.
