•
•
•
•
What is DaniWeb IT Discussion Community?
You're currently browsing the ASP.NET section within the Web Development category of DaniWeb, a massive community of 402,743 software developers, web developers, Internet marketers, and tech gurus who are all enthusiastic about making contacts, networking, and learning from each other. In fact, there are 2,506 IT professionals currently interacting right now! Registration is free, only takes a minute and lets you enjoy all of the interactive features of the site.
Please support our ASP.NET advertiser: Lunarpages ASP Web Hosting
Views: 680 | Replies: 2
![]() |
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.
When Autumn Falls [ http://www.whenautumnfalls.co.uk ] &&
Designdotworks [ http://www.designdotworks.co.uk ] Web / Graphic / Software Design
Designdotworks [ http://www.designdotworks.co.uk ] Web / Graphic / Software Design
•
•
Join Date: Jan 2006
Location: Its the internet... i am everywhere lol
Posts: 274
Reputation:
Rep Power: 3
Solved Threads: 10
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
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
•
•
•
•
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
When Autumn Falls [ http://www.whenautumnfalls.co.uk ] &&
Designdotworks [ http://www.designdotworks.co.uk ] Web / Graphic / Software Design
Designdotworks [ http://www.designdotworks.co.uk ] Web / Graphic / Software Design
![]() |
•
•
•
•
•
•
•
•
DaniWeb ASP.NET Marketplace
•
•
•
•
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
- Good books on Shell Programming/Perl (Perl)
- Good Ol' Windoze 9x (Windows 9x / Me)
- Where can I buy a good computer? (Geeks' Lounge)
- Know of a good program? (Web Developers' Lounge)
- Good Luck! (Geeks' Lounge)
- ThemeXP is back! (Windows NT / 2000 / XP / 2003)
Other Threads in the ASP.NET Forum
- Previous Thread: Problem with ContentPlaceHolder content format in IE, ok in Firefox
- Next Thread: using summation and aggregate expressions on datagrid/view


Linear Mode