Planning the Application

[traceytr]

I’m a newbie to VB.NET and need some advice in planning a small application. I have a solid VB6 background but haven’t done any new development in 22 months -- I’ve been repairing and enhancing third party software (not .NET.)

At long last, I have a small programming project in VB.NET 2003, and I don’t want to jump right in without a good plan. (I haven’t received a functional spec yet, and will probably not get a technical spec.) I’m not looking for someone to code this for me, although I'd be grateful for any code examples. Mostly, I just want to know my work is headed in the right direction.

Currently, we receive text files from customers into DirectoryA. They’re in the right format, FormatA, and work with an existing process, which grabs the files and imports them into a database. This works and does not need to be changed.

However, a new process will be implemented to send us customer text files in a different format, FormatB. The text files in FormatB cannot be directly picked up by our existing process and imported into the database due to the different format. The FormatB text files will land in a different directory, DirectoryB, not in DirectoryA with the text files that are received in FormatA.

The program I’m asked to develop will not have a user interface. It will watch for text files in FormatB to land in DirectoryB on our application server. The program needs to create a text file in FormatA, rename per correct file naming conventions, and place the new file in DirectoryA where it will be picked up by our existing process. Also, I need to move the FormatB file (unconverted FormatB) into new directory DirectoryArchiveB.

For this new application, assume the new files, FormatB, have landed by magic into DirectoryB. (It’s not a high volume of text files – eventually we may get a few hundred per day, but we currently less than 100 customer text files.)

My first impulse is to create a Windows Service. I’ve been looking into the FileSystemWatcher to watch for new files, however I’m hearing we will process new files twice per day, not just whenever they land there. Also, I’ve been playing with StreamReader and StreamWriter to do the text file conversion. I’m VERY new to VB.NET and would appreciate any and all discussion of this. Thank you, thank you, thank you...

Tracey

 

[ThatRickGuy]

I would agree with you on the Windows Service. If you are only going to process files at specific times, instead of when they arive, I would say add a timer to your service with a 1 minute interval. Each minute check the time to see if it is time to transfer. For ease of maintenance, I would stick the transfer times in either an INI file or the app's config file.

Stream Reader and Stream Writer should work fine if you're working with a flat text file. If you're working with XML you may be able to use the Dataset objet's .ReadXML and .WriteXML though.

As for the jump from VB6 to VB.Net... forget everything you knew about VB6. Get rid of the "On error goto ..." statements (Try/Catch blocks are much nicer to work with). There's a few good intro FAQs on the site here, just click the FAQ link at the top of the page.

-Rick

VB.Net Forum forum796 forum855 ASP.NET Forum
I believe in killer coding ninja monkeys.

 

[traceytr]

I'm working with flat text files, not XML, so I'll continue with StreamReader and StreamWriter.

I learned this afternoon that the files will have to be processed as soon as they land in the directory -- not just a couple of times a day like I said earlier. Do you think I should use FileSystemWatcher or do you recommend something different and better? Thanks again for any ideas and comments. I will read through the FAQs as you suggested.

Tracey

 

[ThatRickGuy]

FileSystemWatcher is probably the best tool for the job.

-Rick

VB.Net Forum forum796 forum855 ASP.NET Forum
I believe in killer coding ninja monkeys.

 

[cjelec]

You could build your app with both FileSystemWatcher and Timer based functions, so if the customer changes the spec later on, your not having to start from scratch...

Rick's is right, forget vb6. Look at vb.net as a different language.

With this kind of app, I first build a test version, which is a windows form application. It almost always has a logging screen using a ListView (detail style) and log every thing the app does, this helps you see what the app is seeing and helps you identify proplems. For testing, I also build a second app to create the data (in your case text files), and a database (Microsoft SQL Desktop Engine is free). Build every thing into independant Classes and Modules. Then when i'm happy with the results and everything is working, I build a new app as the beta tester (with text file based logging) for the customer to try it out. The customer will identify problems that you can fix on your own test version and perform the same process again (build test, test, build beta). When both you and your customer are happy with the app, build the final app (with windows environment logging).

 

[traceytr]

I appreciate the advice. I thought I might build a Windows application to start with so I could debug more easily and then move the logic into a Windows service. It sounds as if you have been down this road many times. This is my first time, so I'll probably hit every rock in the road... Thanks, and I'm sure you'll see me posting again as I move through through this project.

 

[ThatRickGuy]

A small recommendation to save yourself some pain...

Build the functionality in its own class. Then call that class from your windows application. Later, when you want to switch from the windows application to the windows service, all you have to do is add that functional class to the new project. It will save you a lot of time and effort in the long run to separate the business logic from the presentation logic now.

-Rick

VB.Net Forum forum796 forum855 ASP.NET Forum
I believe in killer coding ninja monkeys.

 

[traceytr]

I knew I came to the right place.
* Forget VB6 – So far I’m seeing that VB.NET is a whole different animal than VB6.
* Use both FileSystemWatcher AND Timer based functions so I don’t have to start over if/when the customer changes the spec. (The spec IS a moving target at this point.)
* Build everything into independent Classes and Modules.
* Build the functionality in its own class to be called from the windows application so when I switch to the windows service, I’ll add that functional class to the new project. (I’m all for saving myself some pain.)

My next question is: Okay, so how do I do that? I’m just kidding of course. It sounds like a great plan – some very high level advice, which is exactly what I needed. Thank you so much, and wish me luck with figuring out the details.

 

[ThatRickGuy]

Good luck! And feel free to come back any time with technical or design questions.

-Rick

VB.Net Forum forum796 forum855 ASP.NET Forum
I believe in killer coding ninja monkeys.

 

[cjelec]

One more thing, comment everything (comment the comments if needed)... It helps when you go back to the project 6 months or so down the line, and think what the ???
Its best to start commenting in the debug version and add new comments as you go along, put a +/- next to the ones that are still/not relevant.