Deploying ? a trivial little project

[realolman]

I guess you told me.

Fact is I got the book Object Oriented Programming for Visual Basic.NET on your recommendation about a year ago.

I read it completely through. I don't understand it. Maybe I am that dumb.

Denaes:
I/O (saving to/from files) was a damn simple thing in VB6. In VB.net it was more involved.


Why should that have given you trouble? Why would it not get easier in every version? The fact that things do not get easier, but more complicated is what I am talking about...

I started this thread by asking how I get my crummy little app on other machines. In VB6 it take 2 keystrokes to make it an .EXE, and I figured it out myself. It couldn't be much simpler. It should be easier in NET. It's a new version. I shouldn't even have had to come here to ask. When I tried to figure it out in Help, I got a convoluted runaround, and nothing useful. I don't understand why you would not have noticed that, when you used it.


This is one of the help subjects I found when I could not figure out to do it.

Deployment Via Distributable Media

The deployment tools in Visual Studio .NET can be used to create Windows Installer (.msi) files that can be distributed and installed on other computers. The resulting installer files can be distributed on traditional media such as floppy disks or CD-ROM, or they can be placed on a networked drive for installation across a network.

To deploy an application, you first create a Setup project and set deployment project properties that determine where and how the installer will be built. For deployment via traditional media, you would then copy the .msi file from the build location to a floppy disk or other media. To deploy to a network location, you would create a Web Setup project and add the project output group for the application to the Web Setup project in the File System Editor. After building the installer, you would copy it to the server computer, where it could then be downloaded over the network.

Do you really think that this is pertinent, good quality help?

Someone who knows how to do it will not be reading help, Someone who does not know how to do it will not get anything out of this. And this seems to be the rule, rather than the exception. I think it should be MUCH better

I chased the help links around in circles and never did get anything out of it. Rot13 explained it pretty well.

Seems to me Microsoft should contact Rot13 for help on their help.

 

[IngisKahn]

I/O (saving to/from files) was a damn simple thing in VB6. In VB.net it was more involved.


Why should that have given you trouble? Why would it not get easier in every version? The fact that things do not get easier, but more complicated is what I am talking about...

Was it really so simple?

Dim fileNum As Integer
fileNum = FreeFile
Open "MyFile.dat" For Binary As #fileNum
Dim data As String
data = Space(LOF(fileNum))
get #fileNum, , data
Close #fileNum

Compare that to:

Dim reader As StreamReader = New StreamReader("MyFile.dat")
Dim data As String = reader.ReadToEnd
reader.Close

In VB6 it take 2 keystrokes to make it an .EXE, and I figured it out myself.

It's just as easy to build an EXE in .NET, but be it VB6 or .NET you need to ensure that the user has the runtime installed.
And do you think it's easier creating a VB6 install project than a .NET msi?

There's no need to get so defensive; we're trying to answer your questions and concerns, not make you upset.

 

[PlausiblyDamp]

It hardly takes a lot of keystrokes to build a .exe in .Net either though, do it straight from the build menu and every time you run the app it is building a .exe - I fail to see how this is harder than VB6.
If you wanted to deploy a VB6 application you still needed to make sure the runtimes were installed (and the correct versions if you had serviced packed your installation), deploying a .Net application isn't any different in that respect.
In regards to Rot13's help - it will only be of use if the destination PC has the framework installed, otherwise it will not run.

 

[realolman]

Nothing is hard if you know how to do it.

I did not know that the IDE was building the exe every time you ran it. How in the world is a person supposed to anticipate everything MS might have decided to change?


Denaes posted the "I/O (saving to/from files) was a damn simple thing in VB6" line, not me.

My point was that with new versions things should get easier for someone with experience with the product to do... perhaps they did, but they also got considerably different in many ways... which makes it hard.

I am, as Denaes points out "painfully ignorant"; and yes, it is painful.

It's not that I have any great pining love for VB6, or I wouldn't be here.
It's only a matter of time untill VB6 won't run on anyone's computer.

I knew how to read and write to a file, sequentially and random access in VB6 and GWBASIC. You obviously know how to do it, both then and now. I only know how to do it then... and that way no longer works. And that goes for a whole bunch of other stuff as well.

I am a simple guy. I have no interest in databases or networks. What I would like to do is use my computer to figure out how many gallons of heating oil I have in my tanks, and collect when and how long my furnace runs, the chimney and the outside temperature and the temperature of the boiler. Stuff like that. I have a I/O board I bought in the eighties that runs on BASIC and would collect things like that. If I could get at memory locations like I could with GWBASIC under MSDOS, I could make my own board.

It seems to me that there should be a programming languange that would be easy to use to do stuff like that. As Yosiminte Sam would say, "And that programming language oughta be you (VB)".

But nobody uses serial ports any more... do they Microsoft? ( The SAX stuff doesn't work ) To me, MS has thrown out what should have been expanded upon, and changed things seemingly to me, arbitrarily. I am sure you knowledgable people know why it needed changed, but I don't. I don't mean that sarcastically, and I really don't want an explanation... I think they could have kept the old stuff, along with the new.

I know I could buy something that would do what the seller wants me to do with it... I have a thing here that - strangely enough hooks up to the serial port - and works fine... if all you want to do is look at a graph of the input voltages. You can't collect any data and use it in variables in a program.

I want to use my computer for everyday real world purposes. I don't want to buy something... I want to write something ... like I used to be able to do, only with the newest versions of the language.

 

[Denaes]

Nothing is hard if you know how to do it.

Very true.

I did not know that the IDE was building the exe every time you ran it. How in the world is a person supposed to anticipate everything MS might have decided to change?

That was in the first chapter or two of the OOP using VB.net book you read from cover to cover.

It explained how use the framework's command line interface to build & link .EXE's and .DLLs, basically (and then in more detail) what was happening when you precompiled your data into an IL .exe

I'd say that it's the best .Net book I've read overall, but it should be your second or third book, not your first.

Denaes posted the "I/O (saving to/from files) was a damn simple thing in VB6" line, not me.

I agree I'm not the master of VB6 - I could get by on many basic tasks.

For all I know I/O in VB6 could have been more complicated than .Net and I never got into it. But...

Dim reader As StreamReader = New StreamReader("MyFile.dat")
Dim data As String = reader.ReadToEnd
reader.Close

Is a pretty basic scenario and not really capturing the essence of I/O in .Net.

The VB6 Input method was dead simple, though took more steps/lines.

In .Net you should learn what your streams are and how to properly configure them, which is more complicated and in depth than any I/O in VB6 I'd done.

You can get by in VB.Net I/O with VB6 compatability methods and/or using the defaults, but you're going to see massive performance hits for it on large files.

To do it right, it's more complicated. Not hard to learn/impliment, just a few more steps you need to learn.

My point was that with new versions things should get easier for someone with experience with the product to do... perhaps they did, but they also got considerably different in many ways... which makes it hard.

I agree things should be streamlined and they were. Not really harder, just a different way of thinking. An OOP way of thinking.

If it helps any, MS is combining commonly used tasks into the "MY" namespace in VB2005. I havn't played with them yet, but I've seen a few time savers.

You can do this yourself. If you're, for example, using I/0 in a specific way and plan to use that format more than once, create a class (myIO or something like that) and a Write, Append, ReadLine & ReadWhole functions where you're doing all the fine tuning inside. Feed it a path to read, it'll return a string. Give it a string and the path and have it save/append the string to the path.

From then on you only need to declare the variable for the class (myIO or whatever you called it) and then call the method. You still had to learn how to do it, but now it's dead fast.

But it's very important to have those options. It's very important to be able to configure your stream and reader/writer, otherwise it won't do what people need and/or it would take up multiple methods and that would make things more complex and messy.

I am, as Denaes points out "painfully ignorant"; and yes, it is painful.

I knew how to read and write to a file, sequentially and random access in VB6 and GWBASIC. You obviously know how to do it, both then and now. I only know how to do it then... and that way no longer works. And that goes for a whole bunch of other stuff as well.

What you said about all .Net books being useless or whatever you said was ignorant. It's pretty clear you havn't fully read a VB6 to .Net or Beginning .Net book. The basic VB.net books I learned on (Mastering VB.Net & Schneiders VB.Net) explained the .exe and framework situation and even compared it to the VB6 runtimes and Java interpreter.

They also explained at least the basic concepts & parameters you need for I/O to read/write and append a file.

I think you either didn't read basic "intro to VB.Net" books and got bogged down in things you didn't know or just skipped around and didn't read the basic books fully, testing and applying your knowledge as you went.

I don't know. It sounds like you know what's going on for some things, but are totally in the dark for others.

Like this running an app on another machine. It's a step easier than VB6.

You copy the file to a disk (or download it) and if the file doesn't run, install the .Net framework (again, from disk or download it). Same thing you had to do with VB6. The part where .Net is easier is that you don't need to register .dlls with the machine. You can just leave them in the directory with the .exe and copy them over as well.

I am a simple guy. I have no interest in databases or networks. What I would like to do is use my computer to figure out how many gallons of heating oil I have in my tanks, and collect when and how long my furnace runs, the chimney and the outside temperature and the temperature of the boiler. Stuff like that. I have a I/O board I bought in the eighties that runs on BASIC and would collect things like that. If I could get at memory locations like I could with GWBASIC under MSDOS, I could make my own board.

That sounds really cool, and somewhat beyond my comprehension of GWBASIC or even VB6.

I don't think trouble with this is so much a .Net thing as the fact that newer computers don't support it, so MS isn't supporting it. My desktop and laptop don't have serial ports, just USB & Firewire.

I'm not sure how dead Serial is, but you'll have that problem with anything newer... New technologies only support dead/dying technology up to a certain point.

 

[mskeel]

If I could get at memory locations like I could with GWBASIC under MSDOS, I could make my own board.

I know this has nothing to do with the original post, but you might be better off with strait up C instead of VB.net for that. Right tools for the job, you know? As far as I know, you don't have the kind of memory access/control in VB.net. Does anyone know if you could you get it in C# within an unsafe code blocks? I would be inclined to think so but I am unsure as I havn't interfaced with the sorts of I/O boards your talking about via C#.

 

[realolman]

I think you're bangin' on me a bit hard there Denaes.

I have 6 books. Have I read every line, no. Have I been giving it a shot ,yes.

I follow along with a demonstration of inheritance that takes about 36 lines of code so that when you check a check box, it changes color instead of appearing checked. I'm sorry, that's not very inspiring. I remember when I read my first book on the BASIC language, I literally jumped up out of bed and stood on the bed reading the book; the implications made my blood boil.

I never have been able to realize those implications, I think to a large degree, because Bill Gates keeps pulling the rug out. I feel like I have to start all over (again) and that makes me angry.

The stuff I am talking about is very cool. I do some similar things at work with programmable controllers and what not. It amazes me how close much of what you gotta pay Rockwell thousands of dollars for their software is to VB. It is so close... and yet so far.

I'm going to show my ignorance again :
How can you use the stream reader thing that you posted to read and write discrete pieces of information? Suppose I have five seperate pieces of data, some numerical and some strings, and I want to be able to perform some mathematical operation on the numbers and keep them straight from the strings. How to I keep them seperated so that I know which is which? It seems that much of this stuff is for entire files, in which case couldn't you just use windows explorer. (They don't have an ignorant emoticon)

Can you communicate with a USB port with VB.NET?

 

[Machaira]

I follow along with a demonstration of inheritance that takes about 36 lines of code so that when you check a check box, it changes color instead of appearing checked. I'm sorry, that's not very inspiring.

Well, you can do it in a few less lines of code (this is just one way):

    Private _val As Boolean = False

    Private Sub CheckBox1_CheckedChanged(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles CheckBox1.CheckedChanged

        Static lock As Boolean

        If Not lock Then
            _val = Not _val

            lock = True

            CheckBox1.Checked = False

            lock = False

            If _val Then
                CheckBox1.BackColor = Color.Blue
            Else
                CheckBox1.BackColor = Color.White
            End If
        End If

    End Sub

I think what they were trying to show is not so much changing the color of the checkbox, but the power and functionality of inheritance. Without having read the book I could be wrong, but usually examples in books aren't really something you would do in real life.

I never have been able to realize those implications, I think to a large degree, because Bill Gates keeps pulling the rug out. I feel like I have to start all over (again) and that makes me angry.

It's not so much starting over. Much of the language is still the same. You just have a huge pre-built library of classes to use.

I'm going to show my ignorance again :
How can you use the stream reader thing that you posted to read and write discrete pieces of information? Suppose I have five seperate pieces of data, some numerical and some strings, and I want to be able to perform some mathematical operation on the numbers and keep them straight from the strings. How to I keep them seperated so that I know which is which? It seems that much of this stuff is for entire files, in which case couldn't you just use windows explorer. (They don't have an ignorant emoticon)

First, a StreamReader is just what is says - a reader. You would use the StreamWriter class to write data back out to a file.

Second, the class just reads in file data to memory, you would still do the manipulation using variables. For your example how you would read in the data depends on how you have it set up in the file. If it's all on one line in a delimited format you just read the line into a string variable and using the String class's Split function to chop the line into it's separate pieces of data. If it's on separate lines, use the ReadLine to read each piece into separate variables.

Hope that's enough of an explanation.

Can you communicate with a USB port with VB.NET?

Not "out of the box" AFAIK.

 

[Nerseus]

@realolman:
I would question why you'd want to use .NET? Surely you don't buy into "newer is better". If you know/like VB6 better, use that. You have a specific need, it sounds like - to control some custom hardware through Serial and/or USB ports. That's not a normal target of .NET developers, which are mostly business oriented. What's cool for me and what makes my life easier may just add extra complexity to what you want. If an old version of QBasic works, I'd use that. Maybe Borland has a new version of Turbo Pascal (which I loved back in the DOS programming days) for windows? I'm not that familiar with COM port programming, but I know lots of people used VB5 and VB6 for that, along with a 3rd party COM port "control". I'd look down that path, if that's what you really want.

-ner

 

[realolman]

@realolman:
it sounds like - to control some custom hardware through Serial and/or USB ports. That's not a normal target of .NET developers, which are mostly business oriented.
-ner

I suppose I'm beating a dead horse, but what I'm trying to communicate here is what in my mind should be... while trying to learn what is.

Is there any reason this stuff couldn't be included with vb.net? It used to be included with basic and vb6. Would it make .NET too large and unwieldy? Is USB outdated already too? Weren't there other languages for business? I really feel that I am trying to not argue here. I truly would like to understand.

It seems to me it would be relatively small potatoes for MS to include stuff like this. It's very difficult to buy a tape recorder ( Geeze, am I old ) with a microphone jack. On the other hand Mp3 and CD players don't have microphone jacks either. Individual creativity is being phased out. Should no one be able to program a computer unless he works full time at it... for a large company? Should we have to buy a program to do everything? Or better yet subscribe to a program?

 

[realolman]

I think what they were trying to show is not so much changing the color of the checkbox, but the power and functionality of inheritance. Without having read the book I could be wrong, but usually examples in books aren't really something you would do in real life.
.

That's exactly what it was for. I didn't think an example like that demonstrated much usefulness in inheritance. You'd think they could do better... they ARE Microsoft

Second, the class just reads in file data to memory, you would still do the manipulation using variables. For your example how you would read in the data depends on how you have it set up in the file. If it's all on one line in a delimited format you just read the line into a string variable and using the String class's Split function to chop the line into it's separate pieces of data. If it's on separate lines, use the ReadLine to read each piece into separate variables.

Hope that's enough of an explanation.
.

You are very kind in your explanation. Thank you.

In the old days, you would write to a file, using commas for delimiters and then when you read it, it would be up to you to keep everything sorted out, by inputting it in a similar manner as you wrote it, and assigning things to appropriate variables. Is that sort of what you do now?

I guess you could have written every thing in one big string before, and then InString'ed, Left, Right, and MidString'ed it it and took it back apart, but I don't see why you would want to do that. I guess I don't see why you would want to StreamRead and Write it now in one big string.

 

[mskeel]

I guess you could have written every thing in one big string before, and then InString'ed, Left, Right, and MidString'ed it and took it back apart, but I don't see why you would want to do that. I guess I don't see why you would want to StreamRead and Write it now in one big string.

realolman, it's time to embrace change. I used to think pretty much the exact same as you do, "It doesn't do what I need it to do in the way I am used to doing it, therefore, VB.Net is terrible and stupid." I had to force myself, painfully at first, to write programs. What I ended up with were C++ programs written in VB .Net. It wasn't what I was used to (it's so wordy!) but it got the job done. After a while I started to figure out how to do exactly what I wanted to do and then VB. Net wasn't so stupid any more (though I still think the differences when passing a reference variable to a method byref vs byval is kind of dumb). Soon, I stopped thinking of Sub as a silly way to make a function void and it simply became a Sub or a Function.

Anyway, the point is, the harder you think about how it is different from what you are used to, the greater the difference you will find. It sounds like you have the basic tools and experience to write programs -- now you just have to put it all together using a new language. It's sort of like English, right? If you have a great English vocabulary, that doesn't just disappear when you are speaking Spanish. You may not know the Spanish word for something you know in English, but that doesn't mean you don't know what it is AND you can always look it up in a dictionary to get the word. The MSDN can be your VB6 to VB .Net dictionary and it's not like you suddenly have lost the ability to create algorithms or write programs.

Start small to get the hang of things first. Embrace the change but don't forget where you came from. Pretty soon you'll be coding hard core and you'll be that much better off than before. Start looking for the similarities, make the "translation" when you need to (void function = Sub, VB6 Runtime = .Net Framework), and pretty soon you'll be a total VB .Net pro.

Of course, all that said, you should always use the right tools for the job.

 

[Nerseus]

Here's a link to the book "The Design of Everyday Things". This could have been written by realolman. Maybe if he wasn't too busy trying to get his computer to do what he wants

I guess I'm saying I agree with realolman. VB3 was perfect, in my opinion, for picking up (loaded lightning fast) and just getting something done. The changes MS has made has been perfectly intune with what I want/need at work, but that's not the type of work everyone does. Although I don't know of one, I'm sure there's a "simple" language out there right now that make your life easier.

The book points out that as we get "smarter" and use technology more, we don't always design things better or smarter. My new fangled digital camera still seems way harder to use than it needs to be. And now I need a program to retouch my photos, one to organize them and another to find/eliminate the duplicates. Egads, I spend too much time on the computer... have a good night.

-ner

 

[realolman]

Here's a link to the book "The Design of Everyday Things". -ner

You can read pages from the book on the site. All I can say about what I have read is EXACTLY!

I am going to blatantly steal some lines from the book :

The human mind is exquisitely tailored to make sense of the world. Give it the slightest clue and off it goes.

If I were placed in the cockpit of a modern jet airliner my inability to perform smoothly would neither surprise nor bother me.

This ain't no airliner.