im converting a vb6 desktop application to run on an intranet obviously there are some things which will never work but the majority is doable but im quite worried about filesizes. i know the intranet will have faster connectivity than your average web page they are mostly running 100mbps lans and some wireless 54mbps but i just took a look at my average page filesize and it is already at roughly 149kb. There isnt too much more to add in terms of usage but after add in all my user validation, Images and your regular html markup i can see the filesize increasing does anybody know if this will be a problem.

Be careful you dont write your vb6 code on the intranet as you will see big performance losses. You not only have to port it to a web based application but also to .net and asp.net (along with ajax, javascript etc.) all of which will help performance if you use best practices.

File size wont really be too much of an issue when it comes to an intranet application - data will be the bigger problem. Your choice of data objects (business objects, ado.net datasets, the new linq objects (well worth using if you have .net3) xml etc) will all play a vital role.

Without going into too much detail you can look at image sizes (give thumbnails or small images and a way to look at a large image if they want to). Image resolution is a biggie too. A screen is no better than 90dpi so dont have hi res images that are at 300 dpi for printing. Create different sizes of the same image for each place you use them. This will give the smaller file size then.

Data input validation should be done on the client, and then checked on the server, the rest of the logic should all be on the server.

Use Ajax where you can as this will give a more desktop look to your application and also allow you to do a lot more server round trips without page refreshes.

Use pages in grids - dont get all 10,000 records, get them in 20's at a time or whatever works best and let the user choose which page they want next - again using ajax this is seamless to the user.

Dont use Datasets over a network connection - use objects instead as they are faster.

Also consider keeping a desktop application as well as the intranet version if your users are still in the office. Use thin clients and keep everything else on the server - remoting or web services will do this for you :)

Comments
a great help

Be careful you dont write your vb6 code on the intranet as you will see big performance losses. You not only have to port it to a web based application but also to .net and asp.net (along with ajax, javascript etc.) all of which will help performance if you use best practices.

File size wont really be too much of an issue when it comes to an intranet application - data will be the bigger problem. Your choice of data objects (business objects, ado.net datasets, the new linq objects (well worth using if you have .net3) xml etc) will all play a vital role.

Without going into too much detail you can look at image sizes (give thumbnails or small images and a way to look at a large image if they want to). Image resolution is a biggie too. A screen is no better than 90dpi so dont have hi res images that are at 300 dpi for printing. Create different sizes of the same image for each place you use them. This will give the smaller file size then.

Data input validation should be done on the client, and then checked on the server, the rest of the logic should all be on the server.

Use Ajax where you can as this will give a more desktop look to your application and also allow you to do a lot more server round trips without page refreshes.

Use pages in grids - dont get all 10,000 records, get them in 20's at a time or whatever works best and let the user choose which page they want next - again using ajax this is seamless to the user.

Dont use Datasets over a network connection - use objects instead as they are faster.

Also consider keeping a desktop application as well as the intranet version if your users are still in the office. Use thin clients and keep everything else on the server - remoting or web services will do this for you :)

Thanks for a great reply, we currently have a desktop app version of the software but many clients are requesting a .net version that will run with their intranet. Seems like ive actually done most of what you have stated by a bit of thought and blind luck thanks again

This article has been dead for over six months. Start a new discussion instead.