PlausiblyDamp

If the plugins target the functionality provided by an interface (e.g. all the classes you mentioned are vehicles of some kind and will have a lot of similar functionaility - speed, number of passengers etc, this functionality would be what the interface defines), then the plugin will be able to work with any class that implements the interface without needing to be re-written or re-compiled. It may help if you give a bit more detail or even some sample code if possible to see if there is an easier solution to your problem.

My bad, didn't read his post properly :( Still stand by my comment about interfaces being the way to go though...

If you don't have a standard interface you will need to recompile the code everytime you add a new plug-in to the system, that does seem to defeat the point of a plug-in system. It make take a bit of effort to design a suitable interface for your plug-ins but it is the sensible route to take, http://www.xtremedotnettalk.com/showthread.php?t=49597 is most definately worth a look.

http://www.xtremedotnettalk.com/showthread.php?t=94780 may be worth a read as it started with a very similar question.

The OleDbDataAdapter class will allow you to fill a dataset from an ADODB.Recordset, that might be the easiest way to approach this problem.

I can see Extenders being useful in a select number of scenarios (I can also see them being abused far more frequently) when a sealed class doesn't provide a piece of functionality that you use frequently. Also extenders do not have access to the class internals the same way a derived class would so the abstractions and decisions made by the original class are not being compromised. e.g. Strings have ToUpper and ToLower methods but no ToTitleCase - even though the functionality is present (buried away somewhere in System.Globalisation), the ability to easily add a .ToTitleCase() to a string could be useful and the resultant code looks more OO even though it isn't because of the less explicit syntax in calling your static 'helper functions'. e.g string s = "Test string HeRE"; //with extenders s = s.ToTitleCase(); //without s =Utils.String.ToTitleCase(s); Similar ideas could be used for things like normalising white space etc. As the PDC docs themselves indicate though extenders are a tool for specific problems and should be used sparingly, like any other coding construct used correctly it can be a boon; used badly it does more harm than good (a bit like a power tool really ;)). I can see some ease of use from the idea of object initialisers but nothing that gets me overly excited and not coming from a lisp / ruby background I'm not entirely sold on lambda expressions either. Anonymous delegates can help to reduce the number of methods present in a class, especially when the callback etc. the delegate is being used for isn't overly complex, plus the ability to have local variables scoped to the anonymous delegate as well. Not sure about anonymous classes however... Nullable types are again a tool for a specific purpose, when dealing with data access code they can drastically reduce the amount of code for handling null values and associated exceptions. Generics however I do feel are a very worthwhile addition, the amount of code you no longer need to write when dealing with arrays / collections etc is a big time saver, also the lack of runtime errors that need handling, implicit or explicit casting no longer being needed etc all contribute to the quality of the code.

They can also make unit tests involving callbacks / events far cleaner to write as well.

Have you added a reference to System.Windows.Forms.dll? Also yuo will need to add Imports System.Windows.Forms to the top of the code file.

You could always try and see if that works, however I would suggest the XML itself is badly designed - the whole point of XML is storing information not formatting, should not be part of the data.

Edit, Outlining, Collapse to Definitions or CTRL+M followed by CTRL+O

Could you not just use the System.Uri class for your URL processing?

Cache, and it can manage the data lifetime better as well.

You might be better off storing the data in a Cache object instead and specifying a dependency that will cause the data to be expired when underlying DB is modified.

.Net doesn't support multiple inheritance so you can only inherit from a single parent class, this may change in a future version but I wouldn't hold my breath waiting for it. It may be possible (but a bit more code heavy) to use interfaces instead on inheritance to achieve the same effect.

IIRC the framework is included in the CD version of SP but not the downloadable version, you can get the framework runtime from here. If the application was developed against the 1.1 framework that is what you need to install on the test PC and ultimately any PCs that will run your application.

Any chance you could tell us the error you are getting? Also does File1.PostedFile.InputStream point to a valid stream?

How have you defined GetPrivateProfileString in your code? Try the following code and see if it works Private Declare Auto Function GetPrivateProfileString Lib "kernel32" (ByVal lpAppName As String, ByVal lpKeyName As String, ByVal lpDefault As String, _ ByVal lpReturnedString As StringBuilder, ByVal nSize As Integer, ByVal lpFileName As String) As Integer Public Function ReadINI(ByVal INISection As String, ByVal INIKey As String, ByVal INIFile As String) As String Dim StringBuffer As New StringBuilder(2000) Dim StringBufferSize As Integer StringBufferSize = StringBuffer.Capacity StringBufferSize = GetPrivateProfileString(INISection, INIKey, "", StringBuffer, StringBufferSize, INIFile) Return StringBuffer.ToString() End Function

The Dispose method found in DataSets and DataTables is actually due to it inheriting from Component, calling Dispose on a DataTable or DataSet doesn't actually free up the table(s) at all. Also neither of them provide their own finalizer so there is no need to worry about needing to re-register etc. If you need the data to be available then store it in a Session, Application or Cache variable, when it is no longer required clear the Session, Application or Cache variable and let the GC collect it at it's leisure.

Depends on how you are creating the file but all Stream derived classes have a close (and Dispose) method, the various ReaderClasses (StreamReader, BinaryReader etc.) also should have a Close (and Dispose) method. If you are using C# you might want to wrap the stream handling code within a using block to ensure the stream is closed properly.

You would need to check if it is null or if it has been disposed rather than just null. Also if you are hiding the form or anything similar that would also need to be taken into account.

What is the value of strFileName when you get the error?

Put the .cs into a class library project and reference the resulting dll from both the windows and web applications.

If you declare the pagefrmHistory variable outside of the routine then you would be able to just check if it is null or not.

As was pointed out in http://www.xtremedotnettalk.com/showthread.php?t=94730 creating a DataSet that is pretty much an exact copy of your DB schema is not the way to do this, you should create a dataset for each individual business task.

http://www.icsharpcode.net/OpenSource/SharpZipLib/Default.aspx has a good free zip library for the zipping part of your problem. System.IO.Directory and System.IO.File can be used to search for files and obtain information about them.