PlausiblyDamp

http://www.sysinternals.com has a couple of free utilities that might be useful. FileMon and RegMon qill handle the file and registry tracking. Also ProcessExplorer will allow you to see what file handles / dlls are open (amongst other things) by a process.

Have you included the crystal reports merge modules in your deployment package? If not then search these forums and you should find what you need to do.

A vote in a poll will cause it to appear as an unread thread.

Perhaps they are trying to keep similar semantics to value types in general, after all to add to an integer int i = 0; i = i + 3; //or i += 3; //but not i + 3;

.resources are one of the intermediate file types - they are produced from the .resx files in the project itself (either directly or one per form)

IIRC the obj folder is where the intermediate files are generated during the build process, the bin folder is the resultant output.

The graphics object you are drawing to should have a MeasureString method that will return the bounding box for a given string and font selection.

In you sample the code refering to OleDbDataAdapter and DataSet is ADO.Net code, the Recordset however is just plain old ADO cide. If you do not have the OleDb drivers for DB2 installed how are you getting the data into an ADODB Recordset? Your code snippet makes it look as though you have them installed as you are using an ADO Connection to execute the SELECT statement. Alternatively you could use the classes under System.Data.Odbc if you havea DB2 odbc driver installed.

When you go to the add existing item dialog the 'Add' button has a drop down on it's right hand side - click on that part and you can select to add as a link.

Recordsets are ADO not ADO.Net, the .DLL in the interop folder is a wrapper around the COM ADODB.DLL component. If you are running the code yourself then you could just use the classes under System.Data.OleDb directly (OleDbConnection, OleDbCommand etc.).

The limit has now been raised to 25 characters, should make things a little easier to search.

Web services aren't really designed to work that way - they are ultimately a simple client server / request + response system and do not provide a way for the server to push further information down to the client. If you need to do something more complex (request + response + response) then you could possibly implement some form of state management on the server side and have the client periodically poll the server, however this will impact scalability and performance and possibly be far more complicated than is really practical. In your model you are trying to return 2 seperate pieces of information, the fact that a request has been received and then the results - could you not assume the request was received by the fact it didn't fail and report an error? If this is required functionality then webservices may not be the appropriate technology (possibly remoting may be more suitable).

The whole point of the SendAsync method is that it sends asynchronously and doesn't wait. If you need to wait just use the Send method instead. Alternatively as you are handling the call via a callback why do you need to wait?

The counter is part of your page class, every time the page is refreshed the class is created, used and destroyed - this means all instance variables are also lost. You would need to also store the counter variable in the Session state to make it persist between refreshes.

If you are using .Net to call the webservice then you are probably calling it through the generated proxy class generated either by Visual Studio or by the command line WSDL.exe tool. If this is the case then every method should have a BeginXXXX EndXXXX set of methods - calling the Begin method will start the call on a background thread and allow the calling code to continue running. You can later call the End method to get the results. The Begin method also allows you to specify a callback routine so you can be automatically notified when the call completes.

Not sure why the problem you are encountering is occurring, however it might be easier and more standard to just ignore the attempt to paste invalid data into your application - after all it may be perfectly valid data for another application I also intend to paste into; in your scenario it would clear the contents if I tried your app first and the other app second but would seem to work if I attempted it in a different order.

The only real way to know for sure is by running some performance tests on the system and see how it behaves (either under a simulated load or ideally real load) with various caching options and settings in place.

Have you tried using the ThreadPool to allocate the threads for you - this does implement some internal mechanisms to regulate the number of threads spawned based on CPU usage.

Have you tried the C# style cast syntax? AL = (ArrayList) BinaryFormatter.Deserialize(FileStream); That should work as C#'s syntax is taken from the C / C++ way of doing things.

Giving the application a strong name is effectively signing it, this will (amongst other things) detect if the file is modified / corrupted in any way and is a good practice to get into anyway. Under VS 2005 you can do this by bringing up the applications property page and going to the Signing tab.

If you strong name your exe and try again does it have any problems? Is this particular form doing anything different to the rest, like loading other dlls / assemblies?

Not sure what is happening with but = New System.Web.UI.WebControls.ImageButton but = BuildButton(sImageUrl & "N-Home.gif", "btnHome", glob.butHome.sReDirect) but the first of those two lines is redundant as you never use the instance of ImageButton that it creates. If you put a breakpoint on the event handler is it ever reached?

All objects provide a Finalize() method as it is inherited from System.Object.Finalize(), the CLR however ignores that version and will only act on methods declared in derived classes. If the base class doesn't require any explicit clean up (which CollectionBase doesn't - a good thing to check is if it implements IDisposable) then neither does your class. Also if you are going to provide a Dispose method you should really implement the IDisposable interface rather than just provide a method called Dispose().

If your class doesn't have any non-mananged resources then implementing a finaliser will actually cause your class to take longer to be freed up. As a rule if you are dealing with non-managed resources you should implement both IDisposable (correct way to clean up) and a Finaliser (a backup plan for those people who do not call Dispose). For any other type of class just leave the GC to do it's thing.

A bit late to the discussion but http://blogs.msdn.com/ericlippert/archive/2006/04/05/569085.aspx discusses a similar problem when only one of the 2 overloads is generic. The outcome is less than ideal...