//First create FtpWebRequest object with the ftpURL

System.Net.FtpWebRequest ftpRequest = (System.Net.FtpWebRequest)System.Net.WebRequest.Create(CompleteFTPPath);

//Set the ftp Method, like 'UploadFile' for upload

ftpRequest.Method = System.Net.WebRequestMethods.Ftp.UploadFile;

//Give your user name & password of the ftp login

ftpRequest.Credentials = new System.Net.NetworkCredential("username", "password");

ftpRequest.UsePassive = false;

//read your local file with stream and save it in a buffer

System.IO.FileStream streamObj = System.IO.File.OpenRead(CompleteLocalPath);

byte[] buffer = new byte[Convert.ToInt32(streamObj.Length)];

streamObj.Read(buffer, 0, buffer.Length);

streamObj.Close();

streamObj = null;

//read your buffer and save it to the FTP Server

ftpRequest.GetRequestStream().Write(buffer, 0, buffer.Length);

ftpRequest = null;

Option	Votes	%
Yes	265	14.8
Yes, unless they really had no chance of succeeding	364	20.3
Maybe - it's too hard to generalise	379	21.2
No, unless they were really keen or talented	595	33.2
No	187	10.4
Responses	1790

Not a .net Developer?

Are you an asp.net developer? If you aren't don't worry, If you are an ASP.net developer, listen up!
Get Ready for Massive Gains

There are certain things you should take into account when you are developing your applications. Over the last 12 years or so of working with asp and asp.net, I have learned to avoid and do certain things that increase your application performance by a massive amount! Below are my top 20 tips to improving ASP.net application Performance.

1. Disable Session State

Disable Session State if you're not going to use it. By default it's on. You can actually turn this off for specific pages, instead of for every page:

<%@ Page language="c#" Codebehind="WebForm1.aspx.cs" AutoEventWireup="false" Inherits="WebApplication1.WebForm1" EnableSessionState="false" %>

You can also disable it across the application in the web.config by setting the mode value to Off.

2. Output Buffering

Take advantage of this great feature. Basically batch all of your work on the server, and then run a Response.Flush method to output the data. This avoids chatty back and forth with the server.

<%response.buffer=true%>

Then use:

<%response.flush=true%>

3. Avoid Server-Side Validation

Try to avoid server-side validation, use client-side instead. Server-Side will just consume valuable resources on your servers, and cause more chat back and forth.
4. Repeater Control Good, DataList, DataGrid, and DataView controls Bad
Asp.net is a great platform, unfortunately a lot of the controls that were developed are heavy in html, and create not the greatest scaleable html from a performance standpoint. ASP.net repeater control is awesome! Use it! You might write more code, but you will thank me in the long run!

5. Take advantage of HttpResponse.IsClientConnected before performing a large operation:

if (Response.IsClientConnected)
{
// If still connected, redirect
// to another page.
Response.Redirect("Page2CS.aspx", false);
}

What is wrong with Response.Redirect? Read on...

6. Use HTTPServerUtility.Transfer instead of Response.Redirect

Redirect's are also very chatty. They should only be used when you are transferring people to another physical web server. For any transfers within your server, use .transfer! You will save a lot of needless HTTP requests.

7. Always check Page.IsValid when using Validator Controls

So you've dropped on some validator controls, and you think your good to go because ASP.net does everything for you! Right? Wrong! All that happens if bad data is received is the IsValid flag is set to false. So make sure you check Page.IsValid before processing your forms!

8. Deploy with Release Build

Make sure you use Release Build mode and not Debug Build when you deploy your site to production. If you think this doesn't matter, think again. By running in debug mode, you are creating PDB's and cranking up the timeout. Deploy Release mode and you will see the speed improvements.

9. Turn off Tracing

Tracing is awesome, however have you remembered to turn it off? If not, make sure you edit your web.config and turn it off! It will add a lot of overhead to your application that is not needed in a production environment.

10. Page.IsPostBack is your friend

Make sure you don't execute code needlessly. I don't know how many web developers forget about checking IsPostBack! It seems like such a basic thing to me! Needless processing!

11. Avoid Exceptions

Avoid throwing exceptions, and handling useless exceptions. Exceptions are probably one of the heaviest resource hogs and causes of slowdowns you will ever see in web applications, as well as windows applications. Write your code so they don't happen! Don't code by exception!

12. Caching is Possibly the number one tip!

Use Quick Page Caching and the ASP.net Cache API! Lots to learn, its not as simple as you might think. There is a lot of strategy involved here. When do you cache? what do you cache?

13. Create Per-Request Cache

Use HTTPContect.Items to add single page load to create a per-request cache.

14. StringBuilder

StringBuilder.Append is faster than String + String. However in order to use StringBuilder, you must

new StringBuilder()

Therefore it is not something you want to use if you don't have large strings. If you are
concatenating less than 3 times, then stick with String + String. You can also try String.Concat

15. Turn Off ViewState

If you are not using form postback, turn off viewsate, by default, controls will turn on viewsate and slow your site.

public ShowOrdersTablePage()
{
this.Init += new EventHandler(Page_Init);
}

private void Page_Init(object sender, System.EventArgs e)
{
this.EnableViewState = false;
}

16. Use Paging

Take advantage of paging's simplicity in .net. Only show small subsets of data at a time, allowing the page to load faster. Just be careful when you mix in caching. How many times do you hit the page 2, or page 3 button? Hardly ever right! So don't cache all the data in the grid! Think of it this way: How big would the first search result page be for "music" on Google if they cached all the pages from 1 to goggle ;)

17. Use the AppOffline.htm when updating binaries

I hate the generic asp.net error messages! If I never had to see them again I would be so happy. Make sure your users never see them! Use the AppOffline.htm file!

18. Use ControlState and not ViewState for Controls

If you followed the last tip, you are probably freaking out at the though of your controls not working. Simply use Control State. Microsoft has an excellent example of using ControlState here, as I will not be able to get into all the detail in this short article.

19. Use the Finally Method

If you have opened any connections to the database, or files, etc, make sure that you close them at the end! The Finally block is really the best place to do so, as it is the only block of code that will surely execute.

20. Option Strict and Option Explicit

This is an oldy, and not so much a strictly ASP.net tip, but a .net tip in general. Make sure you turn BOTH on. you should never trust .net or any compiler to perform conversions for you. That's just shady programming, and low quality code anyway. If you have never turned both on, go turn them on right now and try and compile. Fix all your errors.

There are hundreds more where these came from, however I really feel that these are the most critical of the speed improvements you can make in ASP.net that will have a dramatic impact on the user experience of your application. As always if you have any suggestions or tips to add, please let us know! We would love to hear them!

Have web development!

Option	Votes	%
Never	593	26.4
When I remember	450	20.1
When I can no longer make out the letters on the keys	299	13.3
At least Annually	264	11.8
At least once a season	239	10.7
At least once a month	203	9.1
At least once a week	138	6.2
Every day	56	2.5
Responses	2242

Do you shutdown your computer overnight?

Option	Votes	%
Always	804	51.8
Only on weekends and/or holidays	157	10.1
Sometimes	260	16.8
Never	330	21.3
Responses	1551

From the get-go, the Web has been a moving target when it comes to a company's ability to stay on top of changing technologies and dynamics.

At first, the Web was mainly a static place, consisting of basic HTML pages. But as the first-mover companies got up to speed, it quickly changed into a place that used CGI (Common Gateway Interface)- and Perl-based applications, along with new security technologies, to enable a whole host of new capabilities—most notably, e-commerce.

And again, just as companies were getting comfortable, XML, SOAP (Simple Object Access Protocol) and other new technologies opened up the world of SOA (service-oriented architecture), completely changing how applications, systems and businesses connected. This was followed by the whole 2.0 phenomenon of blogs, wikis and social networking.

Now, just as your company is finally feeling at ease with 2.0 technologies, the Web is set to move on again.

The next generation of the Web is marked by dynamic, interactive, open and highly flexible applications that not only go beyond the capabilities of classic Web applications but also exceed the features of desktop applications.

In short, this next generation of Web applications is bringing us much closer to a future of the Web as an operating system. And now is the time for businesses to get ready for the latest change in Web technology.

In this IT Planner, eWEEK looks at the five key attributes of these cutting-edge Web technologies and offers some tips on ways that companies can prepare for and even begin building and deploying some of these innovative Web applications.

Step 1: Build Rich Web Applications

When a Web or Internet application is referred to as "rich," it generally means that it is highly interactive, has an intuitive user interface as good as or better than a desktop application, and has a wealth of features and capabilities.

On the Web, a rich application interface will include things such as drag-and-drop capabilities in the places where a user would expect it, contextual drop-down and right-mouse menus, and interactive and real-time data responsiveness when it comes to things such as graphs and reports.

An important thing to understand about a rich Web interface is that it doesn't necessarily entail lots of flashy animations and flashing icons. A simple and plain administrative interface for a server or service application can be extremely rich in the ways it provides information to users and allows them to define settings and parameters.

One of the main technologies in this area is AJAX (Asynchronous JavaScript and XML), a standards-based language that makes it possible to write a rich, browser-based interface that works identically in any standards-based Web browser.

The funny thing about AJAX is that it isn't really a new technology. Most of AJAX is based on established technologies such as JavaScript, but it is used in unique ways to create interactive Web applications.

One of the great things about AJAX is that it doesn't require learning new things. AJAX applications can be built in almost any editing and authoring environment, and tools from Microsoft's Visual Studio to Adobe's Dreamweaver include lots of tools and aids to get up and running with AJAX.

Other products to consider include Adobe's Flex and Microsoft's Windows Presentation Foundation, both of which are designed for developing rich Web applications that can run outside of a Web browser. However, keep in mind that both platforms rely on non-Web technologies, with Flex requiring Flash to run on a system and WPF needing Microsoft technologies such as WPF/Everywhere.

Finally, they say you can never be too rich, but that's not the case when it comes to Web apps: Too much interactivity can ruin a Web application. Just because you can add lots of menus, windows and cool animated graphics doesn't mean that you should.

Step 2: Remain 'Open'-Minded

One of the most amazing technological revolutions of the last 10 years has to be Web services and SOA. If you want proof, think back to the state of application and data integration before XML and Web services came on the scene in the late 1990s.

Back then, doing application and system integration meant dealing with a messy hodgepodge of custom data wrappers, APIs and proprietary connection systems. In many cases, it was nearly impossible for businesses and partners to connect their disparate business systems.

But in a short few years, Web services changed all this. Now, every modern enterprise application, database and framework uses standards-based technologies to easily enable complex and robust data and application integrations.

How did this happen? In a word, openness. Right from the beginning, the world of SOA decreed that if a business, developer or software vendor wanted to play, it had to be based on open standards. Even vendors that had traditionally been inclined to go the proprietary route embraced standards in SOA, clearly understanding that not being able to integrate with standards would leave them on the outside looking in.

In the world of next-generation Web applications, this kind of adherence to openness is just as crucial. Gone are the days when sites and applications could work on just one Web browser and just one operating system.

For the most part, the core technologies of next-generation Web applications make it very easy to stick to both long-standing and emerging Web standards. As noted earlier, AJAX itself is based on common Web standards, and most good AJAX applications should work identically across browsers and platforms.

In addition, standards bodies such as the World Wide Web Consortium and OASIS are currently working on several new formats and standards specifications, such as Compound Document Format, that will add new capabilities for next-generation Web applications.

There is some concern over certain next-generation technologies, such as Flex and WPF. Since these are based on vendor technologies, there is the possibility that they won't be as open as options such as AJAX.

We recommend that businesses choose the open and standards-based path wherever and whenever possible. An application that is written in a proprietary way that makes it difficult to integrate with is one that will not be participating on the cutting edge of Web technologies. If the customers of an application find that it is dictating to them how they can use it, they will most likely stop using it. Sticking to open standards and systems ensures that an application can grow and adapt to emerging trends.

Step 3: Keep Data Dynamic

With old-school Web applications, data is treated in much the same way that a faucet treats water: The application can access the data but doesn't have much control over the data once it arrives.

Next-generation Web applications, in contrast, increasingly are able to handle data on the fly, allowing users to interact with data in real time rather than having to constantly reload the Web application to get new data.

Using technologies such as JSON (JavaScript Object Notation), next-generation Web applications give users more control over the data that is delivered to their applications. They also provide a much more robust level of fault tolerance, making it possible for data to be resident on client systems. This contrasts with the classic client/server-style Web application, where all access to the application and data is lost if the connection is lost. Another important change when it comes to data is the emerging Semantic Web and its related standards and technologies.

Semantic Web technologies will enable Web applications to query and interact with data held in sites and applications across the entire Web, making possible a whole new generation of data-aware applications.

The ability for next-generation Web applications to more robustly handle data also has greatly improved the ability to create and test applications. Many standard Web application development environments make it possible to use small XML and other data files to prototype, debug and test new Web apps.

Well, that may be the vision, but it isn't the reality—and may not be, especially in the United States, for some time.

For next-generation Web applications to truly step to the forefront as alternatives to traditional desktop applications—and even as potential Web-based operating systems—they have to embrace the seemingly old-fashioned notion of offline access.

Think about it: Your company may have created a great new SAAS (software as a service) product that provides lots of value to customers. But if your customer's employees can't use the product during a 6-hour flight, a desktop-bound app might just start to look much more attractive.

The reality of the need to provide offline capabilities hasn't gone unnoticed by major players. Google, one of the biggest proponents of next-generation Web applications, has released a product called Gears, currently in beta, that makes it possible to provide offline access to Google applications.

In addition, Adobe's AIR (Adobe Integrated Runtime), set to ship by the end of the summer, makes it possible to build rich Internet applications that run outside of a browser and can use offline data (yes, this does sound much like a normal desktop application). Further, the Mozilla Foundation is planning on adding offline support in the next version of its Firefox browser.

Step 5: Be Flexible

Right now, many of the tools for offline access are still immature or yet to be released. And there hasn't been much activity related to standardizing offline access to Web applications, meaning that there will be competing and distinct tools for creating offline access for some time. However, businesses should begin evaluating these technologies now. As you build your next-generation applications, don't forget that your users and customers will be asking, "Is there a way to use this application when I'm not connected to the Web?"

Imagine you're a chef in a popular restaurant. You've put together your special dishes for the evening. Hopefully, customers will like them, but if they don't, there's not much that can be done to change the specials—at least not immediately. This is basically the same model for classic Web and desktop application development.

However, now imagine that many of your restaurant customers decide that they want to go into the kitchen and change and adapt your dishes themselves. They like your pasta, but they think they have a better recipe for shrimp. Or they want to use your burger, but add it to a pizza from another restaurant.

This is the model of next-generation Web applications: Users expect to be able to tweak, adapt and change the applications in unique ways to meet their own specific needs. This is often called a mashup.

In this model, your cool new application might find itself combined with an internal business application or mashed up with a popular free application from a big Web portal or search engine. It may even end up being combined with another application from a vendor you see as a competitor.

Especially for software vendors, this can be a scary proposition. In traditional models, these companies try to maintain strict controls over how their applications are used, upgraded and integrated.

But when it comes to next-generation Web applications, locking down your application is a mistake. To many users, a Web application that can't be easily customized or mashed up with other programs is a broken application—and one that won't be used or purchased. Letting users create mashups and allowing them to plug in functionality and integrate your application with other systems is the way to gain user loyalty.

Probably more than anything else, this is the key lesson about next-generation Web applications. The ability of these applications to constantly change and adapt to new technologies, standards and end-user desires will radically change not only Web application delivery but also how people look at all the software that they use.

i had the same problem (login control in page and imagebutton in
masterpage).

the whole asp.net page is usually a form so you have to set the default
button for that main form.

in the Page_Load function of your web page get a reference to the main
form ("form1") which is in master page:

HtmlForm mainform = (HtmlForm)Master.FindControl("form1");

then get a reference to your login button in the login control (convert
your login control in a editable template and you'll see the ID of the
button, however this ID is not directly accessable yet, you have to
search for it with FindControl):

Button loginbtn = (Button)myLoginControl.FindControl("LoginButton");

your main form then wants a unique ID of the default button:

mainform.DefaultButton = loginbtn.UniqueID;

here's the complete code:

protected void Page_Load(object sender, EventArgs e)
{
myLoginControl.Focus();
HtmlForm mainform = (HtmlForm)Master.FindControl("form1");
Button loginbtn =
(Button)myLoginControl.FindControl("LoginButton");
if (mainform != null &&amp; loginbtn != null)
{
mainform.DefaultButton = loginbtn.UniqueID;
}
}

Introduction

In this article I would like to elaborate the process of creating a setup project in Visual Studio.Net 1.1. You can follow same steps for creating installer for any complicated project.

Step I:

Create one Windows based application in VS.Net using any of the Languages i.e. C# or VB.Net.

Step II:

After your program is running and you are ready for the setup. To add setup to your existing application go to Go to File > Add Project > New Project.


After your program is running and you are ready for the setup. To add setup to your existing application go to Go to File > Add Project > New Project.

The window appears like below and you select the Project as Setup Project and give a Name and its Location.

Step III:

After creating setup project right click on project and than select view, it will show different possible operations, which you can perform with this setup project.

The options available are
File System
Registry
File Types
User interfaces
Custom Actions
Launch conditions

Step IV:

Click on File system, it is used to create file system on the target machine. Through this you can specify what details you want to provide at the target machine.

Step V:

Now in the new window, its time to add the files & folder’s used by the application.

First we add the Project Output file. Click on Project Output and a new popup appears. Select the appropriate choice. For a normal project we select as Primary Output File & Content Files.
it is used to create file system on the target machine. Through this you can specify what details you want to provide at the target machine.

To add Icons/Any specific folders, click on Add > Folder and Folder is added. Rename the folder as per your project requirements

After the Folder is create then add the files to the setup. These will be installed in the same fashion on the target machine

Step VI:

Now we are about to create the setup before that we will setup the program icon. To do it we will do this process :

When you click on Browse, a window gets popup. Now as the icons are already added into the application setup, just click on Browse to pint to that icon and click on ok.

Step VII:

Now final step is compile the setup project. After compilation you will notice that it has generated Setup.msi in the same location which you provided when you initially created the setup project.
You can supply this msi the target machine, when you run this msi at target machine it will create a virtual directory as well as create same folder structure, which you have specified in File System. This installer will also install the specified those libraries in the registry which are specified in the Registry.
Now you can browse that application at the target machine in same way as you have done at your own machine.

Introduction

In this article I would like to elaborate the process of creating a setup project in Visual Studio.Net 1.1. You can follow same steps for creating installer for any complicated project.

Step I:

Create one Windows based application in VS.Net using any of the Languages i.e. C# or VB.Net.

Step II:

After your program is running and you are ready for the setup. To add setup to your existing application go to Go to File > Add Project > New Project.


After your program is running and you are ready for the setup. To add setup to your existing application go to Go to File > Add Project > New Project.

The window appears like below and you select the Project as Setup Project and give a Name and its Location.

Step III:

After creating setup project right click on project and than select view, it will show different possible operations, which you can perform with this setup project.

The options available are
File System
Registry
File Types
User interfaces
Custom Actions
Launch conditions

Step IV:

Click on File system, it is used to create file system on the target machine. Through this you can specify what details you want to provide at the target machine.

Step V:

Now in the new window, its time to add the files & folder’s used by the application.

First we add the Project Output file. Click on Project Output and a new popup appears. Select the appropriate choice. For a normal project we select as Primary Output File & Content Files.
it is used to create file system on the target machine. Through this you can specify what details you want to provide at the target machine.

To add Icons/Any specific folders, click on Add > Folder and Folder is added. Rename the folder as per your project requirements

After the Folder is create then add the files to the setup. These will be installed in the same fashion on the target machine

Step VI:

Now we are about to create the setup before that we will setup the program icon. To do it we will do this process :

When you click on Browse, a window gets popup. Now as the icons are already added into the application setup, just click on Browse to pint to that icon and click on ok.

Step VII:

Now final step is compile the setup project. After compilation you will notice that it has generated Setup.msi in the same location which you provided when you initially created the setup project.
You can supply this msi the target machine, when you run this msi at target machine it will create a virtual directory as well as create same folder structure, which you have specified in File System. This installer will also install the specified those libraries in the registry which are specified in the Registry.
Now you can browse that application at the target machine in same way as you have done at your own machine.

Introduction

It is easy to develop your own ASP.NET web application. But making it do some useful things for your users while keeping the design simple and elegant is not so easy. If you are lucky, your web application will be used by more than a handful of users, in that case, performance can become important. For some of the web applications I worked on, performance is vital: the company will lose money if users get frustrated with the slow response.

There are many factors that can result in bad performance, the number of users is just one of them. As a developer in a big corporation, you usually don't have a chance to mess with real production servers. However, I think it is very helpful for developers to take a look at the servers that are hosting their applications.

Your server spends most of its time waiting

Production servers usually host many applications. One of our web applications was not performing well, I suspect that other applications running on the server were using memory and CPU resources that "should" be devoted to our application. The admin allowed me to look at the server machine, what I found was not what I expected: the server had plenty of unused memory and the CPU usage was pretty low, too. It seems the server was idle most of the time.

That means if we design the application differently, we may be able to trade CPU and memory resources for better performance.

Application dependencies

It is typical for web applications to depend on many services running on remote servers. The slow response from those remote servers is likely the real cause of bad performance for a web application. For example, one of our web applications needs to request data from a remote server, a single request alone takes about 3 to 5 seconds. If my application has to make 5 to 7 different requests from remote servers in order to display a web page, then the performance will not be good even if only one user is using the application!

My approach for solving the performance problem was to design the application in a way that each page will make as few requests to remote services as possible. Which means the application will not make a remote request to a backend server until the data is really needed and once the data is retrieved, it will be cached within the application so that it doesn't need to request the same data more than once. This approach worked fine for us until ...

The management decided to change to a new design that would kill our application

What they want is a more user friendly interface. The first page will be designed in a way that as soon as a user landed on that page, he/she will see a summary of all the important information right away. If more detail is desired, the user can click tabs, links, or buttons on that page to display more data.

The problem is, information requested on the first page can only be extracted from data items returned by various remote service calls. There is no single service that can give us such a "summary" of the data.

So there is no choice but retrieving all the data items from remote servers before displaying the first page. The performance became so bad that even developers hated to use the application.

The Solution

Fortunately, our server has extra power to spare and the remote services we need do not depend on each other. After some research, I devised a new way to retrieve data from remote services. Previously, the sequence of steps to get data was as follows:

• Step 1. If data item 1 is not in cache already, retrieve it by calling service 1 synchronously
• Step 2. If data item 2 is not in cache already, retrieve it by calling service 2 synchronously
• Step 3. If data item 3 is not in cache already, retrieve it by calling service 3 synchronously

My idea is, in step 1 while the application is retrieving data item 1, we also let it retrieve other data items in the background asynchronously (and cache the data items once they are received). By the time the app moves to step 2 and step 3, the data items will already be available in cache. Here is the new approach:

• Step1. In this first step we do multiple things:
  • If data item 1 is not in cache already, retrieve it by calling service 1 synchronously
  • In addition, service calls for data item 2 and 3 are issued simultaneously and asynchronously if they are not in cache already
  • Data retrieved with the above asynchronous requests will be cached
• Step 2. If data item 2 is not in cache already, retrieve it by calling service 2 synchronously
• Step 3. If data item 3 is not in cache already, retrieve it by calling service 3 synchronously

Now, let's see the potential difference in performance. With the old approach, suppose it takes 5, 2, 3 seconds to retrieve data items 1, 2, 3, respectively, the total time will be at least 5+2+3 = 10 seconds. With the new approach, since we assume extra server power is available and the remote services are unrelated/independent, the ideal total time will be a little more than the longest of all data requests, which is 5 seconds in this example. So we can reduce the response time by almost 50%!

Let me explain the idea again in using plain English (no plain English compiler needed). Let's say you are ordering 3 dishes in a restaurant.

• The old way: You order from the same waitress 3 times, each time the waitress will bring back a dish from the kitchen and put it on your table.
• The new way: You order from three waitresses at once, they will be working simultaneously to bring three dishes from the kitchen, put the first dish on your table and the other two dishes on the table next to you. When you need the second and the third dish, a waitress will retrieve it from the next table and put it on your table, there is no need to go back into the kitchen again.

Assuming going back to the kitchen is the most time consuming work, we can save a significant amount of time with the new approach.

To see the Implementation follow the link
http://www.codeproject.com/aspnet/PEDLL.asp