PlausiblyDamp

ASP.Net is a server side technology and cannot just access your local drives, imagine the security implications if any web application could open any of your local files.

Rather than a label control you could use the literal control, or alternatively you could use the hyperlink control instead.

http://www.xtremedotnettalk.com/showthread.php?t=87082 http://www.xtremedotnettalk.com/showthread.php?t=72691 may be worth a quick read

Which line does the error occur on? If you step through the code in the debugger what are the values of the objects on the line that the error happens? Are you sure you are assigning valid instances to the variables?

Use a parameterised query or a stored proc (if your db supports them) rather than just concatenating strings.

The line dim dsTeamPlayer As Dataset = New Dataset() in BindDataset needs to be changed to dsTeamPlayer = New Dataset()

http://api.openoffice.org/docs/DevelopersGuide/FirstSteps/FirstSteps.htm seems to indicate that you can use COM to access Open Office.

IIRC you will need to open the ports for either Front Page extensions (bad) or to access the file share directly (bad).

Using a dataset may help but one thing you could do is move the creation of the connection, stored proc and all the parameters outside of that function - currently everytime you execute the function you are opening a new DB connection, creating the command, creating each parameter, then doing the insert and throwing all the objects away.

As far as I am aware it is based on you being logged into the site, if you close you deliberately log out or if you are inactive and your session expires then you will be shown as being offline regardless of your cookie settings. In fact I can see that you are currently off-line as I am typing this.

The problem with injection isn't that they are tacking on extra code; they are convincing you to do this for them Imagine the following code Dim s as string = "SELECT * FROM Customers WHERE CustomerID = '" & TextBox1.Text & "'" and the user enters 'abcd' into the textbox the resultant SQL looks like SELECT * FROM Customers WHERE CustomerID = 'abcd' and is safe (if bad because of the *) code. Now imagine the scenario where the user enters a value similar to the following in the textbox xxxxx' DELETE Customers -- The new SQL is SELECT * FROM Customers WHERE CustomerID = 'xxxxx' DELETE Customers --' This is now a select followed by an inefficient delete (dangerous and performance hurting all in one!). That is the main problem with just concatenating strings together - the server has no idea what your real intention is and just parses the string as if it had been entered into Query Analyzer or similar; sees two separate sql statements and runs both.... If you use parameters you are firstly stating your intention that the string is a parameter to piece of code and not a piece of code in it's own right, and secondly you are able to provide further information in how the data should be handled (data type, size etc) - which can be a godsend when working with things like dates. Without wishing to get into the whole stored proc or not religious war I personally prefer using stored procs, but would always use parameterised queries over string concatenation.

Using the code from sgt_pinky Dim sFile As String = "textfile.txt" Dim sLine As String Dim SR as New IO.StreamReader(file) While SR.Peek <> -1 sLine = SR.ReadLine dim fields() as string = sLine.Split(",") End While SR.Close

It will be displayed as part of the manifestif you look at it through ildasm.exe

You need to refer to the current instance of the parent form - not create a new instance. Read over some of the above posts as they tell you what you need to do.

Have you looked at http://www.xtremedotnettalk.com/showthread.php?t=77613 for a rough idea on how to access your parent form?

The general idea of web.config / app.config files are for basic administrative changes (connectin strings, urls etc.), rather than day to day settings - in fact on XP & 2003 Server a normal user will not have permissions to write to the programs fol. For per user / per machine settings you may be better of using serialisation to store them either under the PC's profile director or within IsolatedStorage.

I normally always set the version manually - I just find it easier to keep track of that way. Is it just explorer showing this or do other tools (ildasm.exe for example) also show the same?

It may help if you give a little more detail about how the file is structured and what kind of variables etc. you are attempting to read into. If you wish to read less than a line the StreamReader has a .Read method that gives you a bit more control over the reading process, or as an alternative you could do a .ReadToEnd and then use something like regular expressions to parse the resulting string.

I would imagine that you would need to loop through each file in the folder and add them in turn to the archive

Easiest way is to assign a value to _Min and _Max within the control's Sub New

Set e.Handled = true within the event handler and it should prevent the key stroke appearing in the textbox

you will need to change the definition of the frmMain class to remove the error. public partial class frmMain : Form

Rather than catching Exception you should be catching one of it's derived classes. If you suspect code may overflow catch OverflowException, if you are dealing with SQL catch SQLException etc. If you want a more specific example post a little code snippet indicating what is failing and I'll knock up a sample.

Decent source code control is a must so you can always back out of any breaking changes. Frequent code reviews or refactoring can help by having 'problem areas' identified earlier and hopefully fixed before the issues get to ingrained into the code base. If you find you have to propagate changes over several places then take a step back and look to see if you could consolidate some of this code in to a method / class. One of the biggest incentives is to work on a project of any size and then come back to it a few months down the line - badly organised, badly commented code becomes an utter nightmare; even if it seemed to make sense when originally written. A bit of time spent commenting etc as the code is written will save a lot of time when you need to debug, maintain or repair...

MS have no plans to remove the Windows API or prevent it to be called - that would be suicide in terms of getting people to adopt their newer platforms. They have however stated a desire to depreciate the use of APIs in favour of newer technologies (Avalon, WinFS, Indigo etc) in future windows releases. Certain APIs may no longer be supported for other reasons however (move to 64bits being one, security another). As a general rule for new projects it pays to look at current / near future technologies and see if they are suitable replacements for older methods; for legacy projects this kind of major upgrade is often not worth the cost - existing technologies will need to be supported.