VB O5 Program Running Problem..Think its .net framework
 

Hey all :)
I've made a prog in VB.Net and am having a weird issue running it, i think the problem could be to do with .Net Framework 2.0

The program, when run from a CD fails to initialze properly according to windows. This only happens on a Windows XP Fresh build, no .net framework 2.0

I think its because the machine doesnt have .net framework 2.0, so, is there anyway of making the program compatible with machines that don't have this?

Any help / Suggestions welcome. Thanks alot

You can go through your program, and see what classes and methods it's using, and check the documentation to see what the required framework version is for those functions. If it's 2.0, post the offending sub/function/code snippet, along with its intended purpose, and we can probably help you rewrite it.

How do i find out which pieces of code are causing the problem?

You could learn to use the debugger.

Failing that, you can check the call stack trace it pops up when your program gets an exception. First you get a little dialog box like this:

http://members.shaw.ca/r.sheppard/error1.gif

Click 'Details', and you get the call stack trace:

http://members.shaw.ca/r.sheppard/error2.gif

Scroll around in that little window until you find the offending line, then check the docs to see if the method/whatever you're using is supported, and how it is to be used.

Common exceptions are caused by a) using a null reference (ie, when an object is 'Nothing' in VB.NET syntax), trying to write to some read-only thing (as any files or databases on a CD will be, by definition), and c) trying to cast one type to another before verifying you can (ie, using CInt(text) when text contains "Hello").

Sometimes the null reference exceptions are a bit tricky to trace, if your code doesn't have the proper checks. Make sure that if a function, whether you wrote it or not, can return such a reference that this is tested for. Don't blindly try to use the object; passing it off to other functions will often cause an exception, and calling a method on it always will.