Need a bit of advice on a .NET project !

DaBreno

Using VB.Net and ASP.Net, I’m attempting to redo a Client-Server system from VB6 which allows the users to select multiple text files in a folder on their machine and output to an Excel report. The need arose because it’s going to be used by a lot of departments who will be requesting all sort of different reports of varying complexity.
So a central system, a website, was proposed so we wouldn’t have to continually uninstall/install a new version every time a report was created in the .Exe.

I’ve currently got a system where a User logs into a Web Page to produce a Report. They select a Report Name and a file to run the report over. The report is output to an Excel spreadsheet. The problem is the files are on the users machine.

What Im currently doing is sending a .Dll from the website to the users machine and running the report from there. This is not great as I can’t list the files on the users machine like I could if it was a client .Exe. Therefore the user has to type in the name of the file rather than select it from a dialog box. Not ideal! Also, I will have to somehow detect if the .Dll on the users machine is older than the one on the site and prompt them to download it again.

Id be interested to hear what ye all think of this mess and any solutions or different approaches ye might have.

Thanks a mil !

Evil Phil

Could you not just write a macro in Excel that would run locally? From what you've said they already have Excel installed.

If not you could upload the files to a temporary folder on the webserver then import the data into the backend db. From there its easy to produce reports.

bonkey

DaBreno wrote:

So a central system, a website, was proposed so we wouldn’t have to continually uninstall/install a new version every time a report was created in the .Exe.
...
Id be interested to hear what ye all think of this mess and any solutions or different approaches ye might have.

I wouldn't use a website

Why not look at the possibility of implementing your "report engine" on a server as some form of distributed service (SOAP-based Web Service, or a whaddyacallem...Enterprise Service?).

Then stick with the traditional thick-client model, and have it talk to the distributed service (using whatever tech is appropriate).

Another (similar) option is to simply store report *Definitions* on the network, and load them dynamically into the (local) reporting engine - again implemented as a thick client. F'r example...I use ActiveReports as my reporting tool of choice in .NET. However, rather than compiling the .rpx files into the .exe, I can load them dynamically from .rpx files stored on a network share, or - as I have just done in a project - store a custom-definition of them in my database, and dynamically re-generate the report template when I need it.

As a final option, you could check out some of the stuff about deployment options for smart clients (either in the MS Patterns and Practices website, or in the info for .Net 2.0 if you can consider using it), which show various methods of having a local win-forms application which is dynamically updateable (i.e. heading towards one-touch or zero-touch deployment)

jc

Peace

Checking the dll version should be easy enough. You can just get the file attributes and check the creation date/moidification date etc etc. You can patcht he rest yourself with google search.

One way of solving you deployment problem could be this:
2 App's (Application A - new app, Application B - your excel/report thing a ma jig)

Create a small app (Application A)which is called when the user click on his/her desktop icon.
Application A's purpose is simply to check the file version on application B against say your folder on the network (where you will drop new versions of Application .
Applicaion A would go something like this:

If ( ClientsMachineAppB.Version <> NetworkFolderAppB.Version )
{
      Copy the Network Version of App B to the local system.
}
Shell App B and Exit App A.

This was used for a small application in a place where i worked previously and was very effective. If ever there was a change in the application then a new .exe was dropped into the folder and the next time the client started the application then the new version weas copied down, if there was a new version.

The good thing about App A is its small and needs little or no maintenace.

I dunno what would happen if you had to copy dll's etc with registering and unregistering them.

Evil Phil

This mightn't be an issue here but its been my experience that end-users favour Excel as a reporting tool because of its versatility. They can manipulate data with ease and they know Excel well.

I don't know much about SQL Server Reporting Services (yet!) but it does export to Excel.

DaBreno

Excel is a requirement of the users since its the only thing their little minds understand. Some interesting ideas but Im going to convince the boss to let me upload the text files. Its the simplest way around this and Im only into .NET this last month.

Thanks for your replies.

Peace

DaBreno wrote:

Excel is a requirement of the users since its the only thing their little minds understand.

AAHHHH, end users.... can't live with'em, can't etc etc

RicardoSmith

I've had to do something similar with Word templates. In the past I've used Workgroup Templates to share/distribute a template on a network share, then I write VBA in the template to do what I want. Worked quite well in the past. If you consider that VBA is VB, then you'll realise you can do anything you want this way. I had templates that checked the version of files, downloaded new version of files and templates etc. Had about 300 users on this with no problems.

Currently I've inherited a system that uses a ASP.NET front end to work essentially the same way as you are doing it. The user sees a list of files on a webpage and selects what they want, this fires up an activeX which give me access to do stuff on their local machine. To be honest its a complete pain in the butt, as soon as I find another way of doing it I will. The shared workgroup template was a simpler and robust method of doing the same thing.