As per Prerak K's update comment (since deleted):
I guess I have not presented the question properly.
Situation is this: I want to load data into a global variable based on the value of a control. I don't want to change the value of a control from the child thread. I'm not going to do it ever from a child thread.
So only accessing the value so that corresponding data can be fetched from the database.
The solution you want then should look like:
UserContrl1_LOadDataMethod()
{
string name = "";
if(textbox1.InvokeRequired)
{
textbox1.Invoke(new MethodInvoker(delegate { name = textbox1.text; }));
}
if(name == "MyName")
{
// do whatever
}
}
Do your serious processing in the separate thread before you attempt to switch back to the control's thread. For example:
UserContrl1_LOadDataMethod()
{
if(textbox1.text=="MyName") //<<======Now it wont give exception**
{
//Load data correspondin to "MyName"
//Populate a globale variable List<string> which will be
//bound to grid at some later stage
if(InvokeRequired)
{
// after we've done all the processing,
this.Invoke(new MethodInvoker(delegate {
// load the control with the appropriate data
}));
return;
}
}
}
Website:
The Web Site project is compiled on the fly. You end up with a lot more DLL files, which can be a pain. It also gives problems when you have pages or controls in one directory that need to reference pages and controls in another directory since the other directory may not be compiled into the code yet. Another problem can be in publishing.
If Visual Studio isn't told to re-use the same names constantly, it will come up with new names for the DLL files generated by pages all the time. That can lead to having several close copies of DLL files containing the same class name,
which will generate plenty of errors. The Web Site project was introduced with Visual Studio 2005, but it has turned out not to be popular.
Web Application:
The Web Application Project was created as an add-in and now exists as part
of SP 1 for Visual Studio 2005. The main differences are the Web Application Project
was designed to work similarly to the Web projects that shipped with Visual Studio 2003. It will compile the application into a single DLL file at build
time. To update the project, it must be recompiled and the DLL file
published for changes to occur.
Another nice feature of the Web Application
project is it's much easier to exclude files from the project view. In the
Web Site project, each file that you exclude is renamed with an excluded
keyword in the filename. In the Web Application Project, the project just
keeps track of which files to include/exclude from the project view without
renaming them, making things much tidier.
Reference
The article ASP.NET 2.0 - Web Site vs Web Application project also gives reasons on why to use one and not the other. Here is an excerpt of it:
- You need to migrate large Visual Studio .NET 2003 applications to VS
2005? use the Web Application project.
- You want to open and edit any directory as a Web project without
creating a project file? use Web Site
project.
- You need to add pre-build and post-build steps during compilation?
use Web Application project.
- You need to build a Web application using multiple Web
projects? use the Web Application project.
- You want to generate one assembly for each page? use the Web Site project.
- You prefer dynamic compilation and working on pages without building
entire site on each page view? use Web
Site project.
- You prefer single-page code model to code-behind model? use Web Site
project.
Web Application Projects versus Web Site Projects (MSDN) explains the differences between the web site and web application projects. Also, it discusses the configuration to be made in Visual Studio.
Best Answer
Thread pool will provide benefits for frequent and relatively short operations by
If you queue 100 thread pool tasks, it will only use as many threads as have already been created to service these requests (say 10 for example). The thread pool will make frequent checks (I believe every 500ms in 3.5 SP1) and if there are queued tasks, it will make one new thread. If your tasks are quick, then the number of new threads will be small and reusing the 10 or so threads for the short tasks will be faster than creating 100 threads up front.
If your workload consistently has large numbers of thread pool requests coming in, then the thread pool will tune itself to your workload by creating more threads in the pool by the above process so that there are a larger number of threads available to process requests
check Here for more in depth info on how the thread pool functions under the hood
Creating a new thread yourself would be more appropriate if the job were going to be relatively long running (probably around a second or two, but it depends on the specific situation)
@Krzysztof - Thread Pool threads are background threads that will stop when the main thread ends. Manually created threads are foreground by default (will keep running after the main thread has ended), but can be set to background before calling Start on them.