Google
 

Monday, May 28, 2007

The mechanism of property in C#

I will show you what's the mechanism of the property feature in C#.

Summary:
1.Write a demo class
2.Compile the demo as library
3.Explorer the library by ILDASM : See the detail implementation of property in IL


1.Write demo class
Here write a demo class: Student.cs

using System;
using System.Collections.Generic;
using System.Text;

namespace PropertyTesting
{
public class Student
{
private string name = string.Empty;
public string Name
{
get { return name; }
set { name = value; }
}
}
}

Save the Student.cs.
2.Compile the demo as library
Open "Visual Studio 2005 Command Prompt" and compile the Student class as Student.dll with the following command:

csc /target:library Student.cs

3.Explorer the library by ILDASM : See the detail implementation of property in IL

Open the Student.dll by ILDASM.
You will see:
All detail:
There other two methods: ( get_Name,set_Name) has been added.

Property Name Detail:
The Name property is actually calling the two methods: get_Name and set_Name
set_Name detail:
There the value is used as a temporary variable with type as string.

get_Name detail:

Conclusion:
1.The property is actually two methods: get_PropertyName and set_PropertyName.
2.The keyword "value" used in set is a temporary variable with the same type as property.
Posted by at No comments:

Friday, May 25, 2007

patterns & practices Team Development with TFS Guide

REF:http://www.codeplex.com/TFSGuide

Welcome to the patterns & practices Team Development with Visual Studio Team Foundation Server project site! This guide shows you how to make the most of Team Foundation Server. It starts with the end in mind, but shows you how to incrementally adopt TFS for your organization. It's a collaborative effort between patterns & practices, Team System team members, and industry experts. This guide is related to our Visual Studio Team System Guidance Project. - J.D. Meier, Jason Taylor, Alex Mackman, Prashant Bansode, Kevin Jones

TeamDevGuide.gif

Download the Guide

Beta 1 Release is Available! Start using the guide today, while we continue to make improvements.

Parts

Part I, Fundamentals
Part II, Source Control
Part III, Builds
Part IV, Large Project Considerations
Part V, Project Management
Part VI, Process Guidance
Part VII, Reporting
Part VIII, Setting Up and Maintaining the Team Environment

Chapters

  • Introduction
  • Ch 01 - Introducing the Team Environment
  • Ch 02 - Team Foundation Server Architecture
  • Ch 03 - Structuring Projects and Solutions
  • Ch 04 - Structuring Projects and Solutions in Team Foundation Server
  • Ch 05 - Defining Your Branching and Merging Strategy
  • Ch 06 - Managing Source Control Dependencies in Visual Studio Team System
  • Ch 07 - Team Build Explained
  • Ch 08 - Setting Up Continuous Integration with Team Build
  • Ch 09 - Setting Up Scheduled Builds with Team Build
  • Ch 10 - Large Project Considerations
  • Ch 11 - Project Management Explained
  • Ch 12 - Work Items Explained
  • Ch 13 – MSF Agile Projects
  • Ch 14 - Process Templates Explained
  • Ch 15 - Reporting Explained
  • Ch 16 - Team Foundation Server Deployment
  • Ch 17 - Providing Internet Access to Team Foundation Server

Guidelines
  • Guidelines: Visual Studio 2005 Team Foundation Server Source Control

Practices
  • Practices at a Glance: Team Foundation Server Source Control

Questions and Answers
  • Questions and Answers: Team Foundation Server Source Control and Versioning

How Tos
  • How To: Add a New Developer To Your Project in Visual Studio 2005 Team Foundation Server
  • How To: Automate Running Unit Test and Code Analysis with Team Build
  • How To: Create Build Notifications
  • How To: Create a Custom Report with Visual Studio 2005 Team Foundation Server
  • How To: Create a Risk Over Time Report with Visual Studio 2005 Team Foundation Server
  • How To: Customize a Report with Visual Studio 2005 Team Foundation Server
  • How To: Manage Projects with Visual Studio 2005 Team Foundation Server
  • How To: Migrate Source code to Team Foundation Server from Visual Source Safe
  • How To: Perform a Baseless Merge
  • How To: Setup a Continuous Integration Build
  • How To: Setup a Scheduled Build
  • How To: Step Through Creating Your Source Tree in Team Foundation Server
  • How To: Step Through Creating Custom checkin Policies for Team Foundation Server
  • How To: Structure ASP.NET Applications for Team Foundation Server
  • How To: Structure Windows Applications for Team Foundation Server
  • How To: Structure Your Source Control Folders in Team Foundation Server

Resources

Team


Feedback


Related Sites


--
Happy day, happy life!
Posted by at No comments:

Best Practices for Accelerating Problem Resolution in .NET Applications and Web Services

The Basics of Microsoft .NET


• Microsoft .NET is Microsoft's platform for building N-tier
applications. Microsoft .NET encompasses a family of products built
on industry and Internet standards that provide for each aspect of
developing (Visual Studio .NET), managing (.NET Servers) and
using Web services.
• Web services is a software technology that is used to connect
applications and users over standard Internet protocols. Web services
can be implemented through Microsoft Windows DNA, Microsoft
.NET, and J2EE applications.
• XML (Extensible Markup Language) is the universal format for
Web services. XML is a set of rules for designing text formats for
data, in a way that produces files that are easy to generate
and read (by a computer), and that are unambiguous and
platform-independent.
• SOAP (Simple Object Access Protocol) is a protocol built on XML.
Using SOAP, applications call each other in a standard, loosely
coupled way, making it possible to build applications that are
distributed across the Internet. If you think of the interactions
between XML Web services as a phone call, XML describes the
things that applications say to each other in their conversations
and SOAP describes how they call each other on the phone.
• CLR (Common Language Runtime) is a core component of the
Microsoft .NET Framework. Similar to a Java Virtual Machine, the
CLR is a native Windows program that provides various services,
such as memory management, security management and error
handling, to .NET managed applications. Programs can be written
for the CLR in any .NET language, including C# and VB.NET.
• ASP.NET, the new version of Microsoft's ASP, is a programming
framework built on the CLR that can be used on a server to build
.NET Web applications.
• ADO.NET, the new version of Microsoft's ADO, provides .NET
applications with optimized access to data sources such as
Microsoft SQL Server, as well as data sources exposed through
OLE DB and XML.
• Remoting is a .NET technology for calling procedures over the
network using XML, SOAP, and HTTP just as if they were hosted on
the same computer (you can think of Remoting as the .NET version
of DCOM).
• Interop is the process of getting managed and unmanaged
objects (e.g. COM objects) to work together.
• Assembly is the .NET logical equivalent of a DLL, a reusable
application component.
• GC (Garbage Collection) is the .NET mechanism for managing
memory, designed to absolve developers from tracking memory
usage and knowing when to free memory.

Common Problems with .NET Applications

Common Problems with .NET Applications
While Microsoft .NET addresses many of the issues historically
associated with building and deploying distributed applications, it
presents many new challenges related to deployment and support.
This is due to the following reasons:
• .NET applications are typically highly distributed; hence problem
triage is complex and time-consuming.
• .NET is a gigantic new set of technologies and concepts. As with
any new software platform, problems are common and inevitable.
• Web services often translate to significantly higher levels of
dependency between applications and a growing number of endusers,
thus increasing the direct and indirect costs of problems and
inefficiencies in the support process.
The following are some of the common problems associated with
.NET applications:

Performance Problems

As with any software environment, performance problems are
common and often difficult to pinpoint. The possible causes for
these problems include:
• Inefficient code ( e.g. frequent exceptions, many large objects,inefficient database calls – using ad hoc queries rather than
compiled stored procedures).
• Memory consumption (e.g. not freeing objects when they are no
longer used, allocating too much memory per request, inadequate
definition of maximum number of Worker and IO threads).
• Improper application settings (e.g. inadequate session-state
provider, buffering disabled on a Web Forms page).
• Interoperability with legacy Windows code ( e.g. marshaling a lot
of data from COM/COM+ to managed .NET objects).
• Infrastructure problems (e.g. bad network response times that
cause degradation in application performance).

Functional Problems

The Microsoft .NET Framework has been designed to free the
developer from dealing with various programming tasks, such
as memory allocations and security. However, just like in any
development platform, coding errors are still in abundance.
Some of the most common coding errors are:
• Incorrect business logic (e.g. incorrect calculation of interest rate).
• Thread deadlock situations.
• A severe error which leads to an application crash.


Configuration Problems

While .NET promises to resolve "DLL-hell" issues, configuration
problems are far from gone. The following detail some of the
common configuration issues with .NET applications:
• Insufficient permissions to access a resource (e.g. no permission
to write to an application directory).
• Incompatible components (e.g. incorrect versions of assemblies or
COM/COM+ objects).
• Incorrect application settings in .NET configuration files
• Conflicts with other applications (e.g. an anti-virus tool that causes a
Web application to restart intermittently).

User Errors

.NET applications are built to serve end-users. As with any software
application, users make mistakes. Some of these mistakes are resolved
quickly, while some take days to figure out.


--
Happy day, happy life!
Posted by at No comments:

C♯ Coding Style Guide

C♯ Coding Style Guide

  1. Keep your classes/files short, don't exceed 2000 LOC, divide your code up, make structures clearer.
  2. Create a directory for every namespace.
  3. When an expression will not fit on a single line, break it up according to these general principles:
     Break after a comma.
     Break after an operator.
     Prefer higher-level breaks to lower-level breaks.
     Align the new line with the beginning of the expression at the same level on the previous line
  4. Don't use spaces for indentation - use tabs!
  5. Block comments should usually be avoided. For descriptions use of the /// comments to give C ♯ standard
    descriptions is recommended. When you wish to use block comments you should use the following style :
    /* Line 1
    * Line 2
    * Line 3
    */
    As this will set off the block visually from code for the (human) reader.
  6. You should use the // comment style to "comment out" code (SharpDevelop has a key for it, Alt+/) . It may
    be used for commenting sections of code too. A rule of thumb says that generally, the length of a comment should not exceed the length of the code explained by too much, as this is an indication of too complicated, potentially buggy, code.
  7. These comments are formally single line C♯ comments containing XML tags. They follow this
    pattern for single line comments:
    /// <summary>
    /// This class...
    /// </summary>
    Multiline XML comments follow this pattern:
    /// <exception cref="BogusException">
    /// This exception gets thrown as soon as a
    /// Bogus flag gets set.
    /// </exception>
    All lines must be preceded by three slashes to be accepted as XML comment lines.
    Tags fall into two categories:
    • Documentation items
    • Formatting/Referencing
  8. One declaration per line is recommended since it encourages commenting
  9. Try to initialize local variables as soon as they are declared.Note: If you initialize a dialog try to use the using statement:
    using (OpenFileDialog openFileDialog = new OpenFileDialog()) {
    ...
    }
  10. When coding C♯ classes and interfaces, the following formatting rules should be followed:
    • No space between a method name and the parenthesis "(" starting its parameter list.
    • The opening brace "{" appears in the next line after the declaration statement.
    • The closing brace " }" starts a line by itself indented to match its corresponding opening
    brace.
  11. Each line should contain only one statement.
  12. A return statement should not use outer most parentheses.
    Don't use : return (n * (n + 1) / 2);
    use : return n * (n + 1) / 2;
  13. if, if-else and if else-if else statements should look like this:
    if (condition) {
    DoSomething();
    ...
    }
    if (condition) {
    DoSomething();
    ...
    } else {
    DoSomethingOther();
    ...
    }
    if (condition) {
    DoSomething();
    ...
    } else if (condition) {
    DoSomethingOther();
    ...
    } else {
    DoSomethingOtherAgain();
    ...
    }
  14. A for statement shoud have following form :
    for (int i = 0; i < 5; ++i) {
    ...
    }
    or single lined (consider using a while statement instead) :
    for (initialization; condition; update) ;
    A foreach should look like :
    foreach (int i in IntList) {
    ...
    }
    Note: Generally use brackets even if there is only one statement in the loop.
  15. A while statement should be written as follows:
    while (condition) {
    ...
    }
    An empty while should have the following form:
    while (condition) ;
    A do-while statement should have the following form:
    do {
    ...
    } while (condition);
  16. A switch statement should be of following form:
    switch (condition) {
    case A:
    ...
    break;
    case B:
    ...
    break;
    default:
    ...
    break;
    }
  17. A try-catch statement should follow this form:
    try {
    ...
    } catch (Exception) {}
    or
    try {
    ...
    } catch (Exception e) {
    ...
    }
    or
    try {
    ...
    } catch (Exception e) {
    ...
    } finally {
    ...
    }
  18. Blank lines improve readability. They set off blocks of code which are in themselves logically related.
    Two blank lines should always be used between:
     Logical sections of a source file
     Class and interface definitions (try one class/interface per file to prevent this case)
    One blank line should always be used between:
     Methods
     Properties
     Local variables in a method and its first statement
     Logical sections inside a method to improve readability
    Note that blank lines must be indented as they would contain a statement this makes insertion in these lines
    much easier.
  19. There should be a single space after a comma or a semicolon, for example:
    TestMethod(a, b, c); don't use : TestMethod(a,b,c)
    or
    TestMethod( a, b, c );
  20. Single spaces surround operators (except unary operators like increment or logical not), example:
    a = b; // don't use a=b;
    for (int i = 0; i < 10; ++i) // don't use for (int i=0; i<10; ++i)
    // or
    // for(int i=0;i<10;++i)
  21. A logical block of lines should be formatted as a table:
    string name = "Mr. Ed";
    int myValue = 5;
    Test aTest = Test.TestYou;
    Use spaces for the table like formatting and not tabs because the table formatting may look strange in
    special tab intent levels.
  22. Pascal Casing
    This convention capitalizes the first character of each word (as in TestCounter).
  23. Camel Casing
    This convention capitalizes the first character of each word except the first one. E.g. testCounter.
  24. Only use all upper case for identifiers if it consists of an abbreviation which is one or two characters long,
    identifiers of three or more characters should use Pascal Casing instead. For Example:
    public class Math
    {
    public const PI = ...
    public const E = ...
    public const feigenBaumNumber = ...
    }
  25. Naming Guidelines
    Generally the use of underscore characters inside names and naming according to the guidelines for
    Hungarian notation are considered bad practice.
    Hungarian notation is a defined set of pre and postfixes which are applied to names to reflect the type of the
    variable. This style of naming was widely used in early Windows programming, but now is obsolete or at
    least should be considered deprecated. Using Hungarian notation is not allowed if you follow this guide.
    And remember: a good variable name describes the semantic not the type.
    An exception to this rule is GUI code. All fields and variable names that contain GUI elements like button
    should be postfixed with their type name without abbreviations. For example:
    System.Windows.Forms.Button cancelButton;
    System.Windows.Forms.TextBox nameTextBox;
  26. Class Naming Guidelines
     Class names must be nouns or noun phrases.
     UsePascal Casing see 8.1.1
     Do not use any class prefix
  27. Interface Naming Guidelines
     Name interfaces with nouns or noun phrases or adjectives describing behavior. (Example IComponent
    or IEnumberable)
     Use Pascal Casing (see 8.1.1)
     Use I as prefix for the name, it is followed by a capital letter (first char of the interface name)
  28. Enum Naming Guidelines
     Use Pascal Casing for enum value names and enum type names
     Don't prefix (or suffix) a enum type or enum values
     Use singular names for enums
     Use plural name for bit fields.
  29. ReadOnly and Const Field Names
     Name static fields with nouns, noun phrases or abbreviations for nouns
     Use Pascal Casing (see 8.1.1)
  30. Parameter/non const field Names
     Do use descriptive names, which should be enough to determine the variable meaning and it's type. But
    prefer a name that's based on the parameter's meaning.
     Use Camel Casing (see 8.1.2)
  31. Variable Names
     Counting variables are preferably called i, j, k, l, m, n when used in 'trivial' counting loops.
    (see 10.2 for an example on more intelligent naming for global counters etc.)
     Use Camel Casing (see 8.1.2)
  32. Method Names
     Name methods with verbs or verb phrases.
     Use Pascal Casing (see 8.1.2)
  33. Property Names
     Name properties using nouns or noun phrases
     Use Pascal Casing (see 8.1.2)
     Consider naming a property with the same name as it's type
  34. Event Names
     Name event handlers with the EventHandler suffix.
     Use two parameters named sender and e
     Use Pascal Casing (see 8.1.1 )
     Name event argument classes with the EventArgs suffix.
     Name event names that have a concept of pre and post using the present and past tense.
     Consider naming events using a verb.
  35. Capitalization summary
    Type Case Notes
    Class / Struct Pascal Casing
    Interface Pascal Casing Starts with I
    Enum values Pascal Casing
    Enum type Pascal Casing
    Events Pascal Casing
    Exception class Pascal Casing End with Exception
    public Fields Pascal Casing
    Methods Pascal Casing
    Namespace Pascal Casing
    Property Pascal Casing
    Protected/private Fields Camel Casing
    Parameters Camel Casing
  36. Visibility
    Do not make any instance or class variable public, make them private. For private members prefer not
    using "private" as modifier just do write nothing. Private is the default case and every C ♯ programmer
    should be aware of it.
    Use properties instead. You may use public static fields (or const) as an exception to this rule, but
    it should not be the rule.
  37. No 'magic' Numbers
    Don't use magic numbers, i.e. place constant numerical values directly into the source code. Replacing these
    later on in case of changes (say, your application can now handle 3540 users instead of the 427 hardcoded
    into your code in 50 lines scattered troughout your 25000 LOC) is error-prone and unproductive. Instead
    declare a const variable which contains the number :
    public class MyMath
    {
    public const double PI = 3.14159.. .
    }
  38. Brace placement example
    namespace ShowMeTheBracket
    {
    public enum Test {
    TestMe,
    TestYou
    }
    public class TestMeClass
    {
    Test test;
    public Test Test {
    get {
    return test;
    }
    set {
    test = value;
    }
    }
    void DoSomething()
    {
    if (test == Test.TestMe) {
    //...stuff gets done
    } else {
    //...other stuff gets done
    }
    }
    }
    }
    Brackets should begin on a new line only after:
    • Namespace declarations (note that this is new in version 0.3 and was different in 0.2)
    • Class/Interface/Struct declarations
    • Method declarations
  39. Variable naming example
    instead of :
    for (int i = 1; i < num; ++i) {
    meetsCriteria[i] = true;
    }
    for (int i = 2; i < num / 2; ++i) {
    int j = i + i;
    while (j <= num) {
    meetsCriteria[j] = false;
    j += i;
    }
    }
    for (int i = 0; i < num; ++i) {
    if (meetsCriteria[i]) {
    Console.WriteLine(i + " meets criteria");
    }
    }
    try intelligent naming :
    for (int primeCandidate = 1; primeCandidate < num; ++primeCandidate)
    {
    isPrime[primeCandidate] = true;
    }
    for (int factor = 2; factor < num / 2; ++factor) {
    int factorableNumber = factor + factor;
    while (factorableNumber <= num) {
    isPrime[factorableNumber] = false;
    factorableNumber += factor;
    }
    }
    for (int primeCandidate = 0; primeCandidate < num; ++primeCandidate)
    {
    if (isPrime[primeCandidate]) {
    Console.WriteLine(primeCandidate + " is prime.");
    }
    }
    Note: Indexer variables generally should be called i, j, k etc. But in cases like this, it
    may make sense to reconsider this rule. In general, when the same counters or indexers are
    reused, give them meaningful names.
  40. A


--
Happy day, happy life!
Posted by at No comments:

A conversion of the popular DotNetNuke web application to C#


REF: http://www.codeproject.com/aspnet/ASPNETnuke.asp

http://code.google.com/p/cs-dotnetnuke/
--
Happy day, happy life!
Posted by at No comments:

What's up with BeginInvoke?

REF :http://www.codeproject.com/csharp/begininvoke.asp

What does BeginInvoke do?

According to MSDN, Control.BeginInvoke "Executes the specified delegate asynchronously on the thread that the control's underlying handle was created on". It basically takes a delegate and runs it on the thread that created the control on which you called BeginInvoke.

Message queue and Message pumping

  1. Every Windows application you create is provided with a thread on startup. It's this thread that calls the Main method of your application.
  2. For a console application, you can write Main to accept user input and process them.
  3. For a GUI application, things are radically different. GUI applications are event based, which means that there needs to be some entity to process and fire events. Windows manages this by creating a message queue for your application. All UI related actions get translated to messages that get posted to this message queue 1. Now, you need someone to read the messages from the queue and call appropriate event handlers. That's what a message pump is for. It basically is a loop that waits for someone to post a message to the queue. Once someone does, it dequeues it and calls the associated event handler.
  4. In .NET GUI applications, the Application.Run method takes care of message pumping.
  5. As an aside, modal dialogs (shown using Form.ShowDialog) have their own message pump whereas modeless dialogs (shown using Form.Show) don't. Which means that you can call Form.ShowDialog from any thread but Form.Show requires the calling thread to be running a message pump. Note that if you call Form.Show from a UI event handler, both the new form and the current form will be sharing the same message pump, which means that if one form is stuck executing one of the event handlers, the other one won't be usable too.

The One Rule

  1. One of the cardinal rules of Windows GUI programming is that only the thread that created a control can access and/or modify its contents (except for a few documented exceptions). Try doing it from any other thread and you'll get unpredictable behavior ranging from deadlock, to exceptions to a half updated UI. The right way then to update a control from another thread is to post an appropriate message to the application message queue. When the message pump gets around to executing that message, the control will get updated, on the same thread that created it (remember, the message pump runs on the main thread).
  2. There are two fundamental Win32 API calls to access and/or modify a control, SendMessage and PostMessage. There is a big difference in the way the two execute.
    1. The major difference is that SendMessage blocks the caller till the message gets processed by the message pump whereas PostMessage returns immediately.
    2. The subtle but important difference is that messages sent using SendMessage aren't queued in the message queue whereas PostMessage messages are.
  3. SendMessage messages are directly "sent" to the message pump. The message pump retrieves and processes messages sent using SendMessage before looking into those in the message queue.
  4. Effectively, there are then two queues, one for SendMessage messages and one for PostMessage messages (which is what we call the message queue). The message pump processes all messages in the first queue before starting with the second.
  5. An interesting observation is that if code does a SendMessage from within the message pumping thread, the window procedure gets called directly, that is, it doesn't go through the message pump.

Why The One Rule Exists

  1. In .NET, property/method calls on a Control object translate to SendMessage calls, so you can easily see how it can turn nasty. PostMessage posts a message to the queue and returns immediately, so there is no chance of deadlock.
  2. There is one other issue with using SendMessage that is not obvious at all. SendMessage, while blocking the current thread, continues to process messages that are sent to the message pump using SendMessage or one of the functions that send nonqueued[ ^] messages. This means that your code must be prepared to handle incoming messages when blocked on a SendMessage call.
  3. To avoid such problems, Windows provides the SendMessageTimeout API function, which when called with the right parameters, will prevent pumping of nonqueued messages when blocked on sending a message.
  4. However, all .NET UI controls use SendMessage, so you can't avoid the problem, unless you are planning on doing P/Invoke.

Why and when to call BeginInvoke

  1. BeginInvoke essentially does a PostMessage.
  2. Whenever you want to update a control from a thread that didn't create it, instead of directly calling the method/property to update it, you need to wrap it in a BeginInvoke call.
  3. According to MSDN: "There are four methods on a control that are safe to call from any thread: Invoke, BeginInvoke, EndInvoke, and CreateGraphics. For all other method calls, you should use one of the invoke methods to marshal the call to the control's thread".
  4. the Control class provides one property and two methods:
    • InvokeRequired: This bool property returns true if the thread on which this property is called is not the thread that created this control. Basically, if InvokeRequired returns true, you need to call one of the two Invoke methods.
    • BeginInvoke: This is a functionally similar to the PostMessage API function. It posts a message to the queue and returns immediately without waiting for the message to be processed. BeginInvoke returns an IAsyncResult, just like the BeginInvoke method on any delegate. And you can use IAsyncResult to wait for the message to be processed, just as usual. And you can call EndInvoke to get return values or out parameter values, as usual.
    • Invoke: This is like the SendMessage API function in that it waits till the message gets processed, but it does not do a SendMessage internally, it also does a PostMessage . The difference is that it waits till the delegate is executed on the UI thread before returning. So while there is a chance for the deadlock problem to occur, you can be sure that the other problems associated with SendMessage won't happen. Invoke returns the value that the function wrapped by the delegate returned.
  5.  The BCL provides a MethodInvoker delegate, which you can use if your wrapped function takes no parameters and returns void. You can also reuse the EventHandler delegate in case your wrapped function's signature matches it. The MSDN documentation says using these delegates instead of our own custom delegates will result in faster execution.
  6. Both BeginInvoke and Invoke check if they are called on the correct thread (the thread that created the control) and if so, directly update the control instead of doing the PostMessage thing. Apart from performance benefits, it also prevents deadlock if you call Invoke from within a method already running on the UI thread.

Invoke and BeginInvoke

  1. There are a few gotcha's with BeginInvoke though.
    • If the function you are calling via BeginInvoke accesses shared state (state shared between the UI thread and other threads), you are in trouble. The state might change between the time you called BeginInvoke and when the wrapped function actually executes, leading to hard to find timing problems.
    • If you are passing reference parameters to the function called via BeginInvoke, then you must make sure that no one else modifies the passed object before the function completes. Usually, people clone the object before passing it to BeginInvoke, which avoids the problem altogether.
  2. Note that the above points are valid for any function that you run as a thread. They're not so obvious when using BeginInvoke, because BeginInvoke doesn't actually create a thread and instead runs the wrapped function on an already existing thread (the UI thread). It still means that there are two threads, so you want to take the same care protecting your shared variables.

A warning

  1. Control.BeginInvoke, which is what we have been discussing so far, works slightly differently from Delegate.BeginInvoke.
  2. Delegate.BeginInvoke grabs a threadpool thread and executes the passed delegate on that thread.
  3. Control.BeginInvoke does not use a threadpool thread, it does a PostMessage to the target window handle and returns.
  4. This is crucial because if it uses threads, then there is no guarantee to the order in which messages are posted and processed by the application.
  5. Also, unlike Delegate.BeginInvoke, Control.BeginInvoke doesn't require every call to BeginInvoke to be matched by an EndInvoke. Of course, if you are using the return value of the method and/or out or ref values, then you need to call it anyway.




--
Happy day, happy life!
Posted by at No comments:

Thursday, May 24, 2007

Projects List

Cow Project( deleted)
http://code.google.com/p/cow-hybridization-information-management/

Cow management.
http://code.google.com/p/cow-management/
--
Happy day, happy life!
Posted by at No comments:
Labels:

VS.NET addin for the Subversion version control system.

REF: http://ankhsvn.tigris.org/



AnkhSVN: A Subversion addin for Microsoft Visual Studio .NET

AnkhSVN is a Visual Studio .NET addin for the Subversion version control system. It allows you to perform the most common version control operations directly from inside the VS.NET IDE. Not all the functionality provided by SVN is (yet) supported, but the majority of operations that support the daily workflow are implemented.

Take a look at some screenshots here.

Progress on the AnkhSVN project is tracked by the CIA.

If you run into problems with Ankh, try either the Users mailing list or join us in the #ankhsvn channel on the irc.freenode.net IRC network.



--
Happy day, happy life!
Posted by at No comments:

Subversion link page

REF: http://subversion.tigris.org/links.html#clients

Books

Clients and plugins

Subversion Language bindings

Repository converters

  • cvs2svn - CVS to Subversion conversion
    cvs2svn has become its own project now, look at:
    http://cvs2svn.tigris.org/

  • p42svn - Perforce to Subversion conversion
    A Perl script which converts a Perforce depot to a Subversion repository
    http://p42svn.tigris.org/

  • rcs2svn - RCS to Subversion conversion
    A Perl script which converts RCS repositories to a Subversion repository
    http://www.coelho.net/rcs2svn.html

  • sccs2svn.py - SCCS to Subversion conversion
    A Python script which converts SCCS repositories to a Subversion repository
    http://sccs2svn.berlios.de/

  • svn-dump2dir and svn-dir2dump - Convert back and forth between a subversion dump file and a subversion dump directory.
    A "dump directory" is isomorphic to a dump file but all of the fields have been exploded out into their own files so that the field length counts are implicit. It is straightforward to hack on or patch the history a subversion repository when in this dump directory form. Also includes a reimplementation of patch that is more helpful when files are missing, as occurs in the incremental dump form. A precise grammar for the subversion dump file format is also provided.
    http://www.cubewano.org/blacktackle

  • SVN Importer - Migrate to SVN from MKS, VSS, ClearCase, Star Team, PVCS, CVS
    http://www.polarion.org/index.php?page=overview&project=svnimporter

  • Tailor - a tool to migrate changesets between ArX, Bazaar, Bazaar-NG, CVS, Codeville, Darcs, Git, Mercurial, Monotone, Subversion and Tla repositories. Supports incremental conversion.
    http://www.darcs.net/DarcsWiki/Tailor

  • vss2svn - Microsoft Visual Source Safe (VSS) to Subversion
    http://www.pumacode.org/projects/vss2svn

Community sites

  • Subversionary - A SubWiki-based site for the promotion of Subversion and for collecting information on how to configure and use Subversion.
    http://www.subversionary.org/

  • SVNForum - A Subversion community help and discussion forum for exchanging information and tips with other Subversion users.
    http://svnforum.org/

  • Subversion Wiki - A Mediawiki-based Wiki for best-practices, configuration and usage of Subversion and related tools.
    http://www.orcaware.com/svn/wiki/

  • openCollabNet - Contains downloads (such as Subversion compiled and tested by CollabNet), technical content, training and ways to interact with CollabNet's Subversion engineers (via forums or the Submerged blog). Become a member and get more, such as a free online Subversion training class.
    http://open.collab.net/

Sites that Offer Subversion Hosting

  • berlios.de: free hosting for open-source projects
    http://www.berlios.de/

    "The goal of BerliOS is to provide support for different interest groups in the area of Open Source Software (OSS). Our aim is to fulfil a neutral mediator function. The target groups of BerliOS are on one hand the developers and users of Open Source Software and on the other hand commercial manufacturers of OSS operating systems and applications as well as support companies."

  • ObjectWeb: open source middleware
    http://www.objectweb.org/

    "ObjectWeb is an international consortium fostering the development of open-source middleware for cutting-edge applications: EAI, e-business, clustering, grid computing, managed services and more." Their hosting software is GForge, with integrated Subversion support. See http://www.objectweb.org/phorum/read.php?f=49&i=37&t=37 for details.

  • CollabNet: commercial software development collaboration platform, with Subversion integration
    http://www.collab.net/subversion/

    "CollabNet Enterprise Edition (CEE) delivers a complete software development and collaboration platform, offered as a managed service, with full Subversion integration. CollabNet also offers Subversion On Demand, a hosted Subversion development environment, and Subversion support and training."

  • CVSDude: free and commercial Subversion hosting
    http://cvsdude.com/

    "CVSDude is a free CVS server and Subversion server. We provide cvs hosting and Subversion hosting for software developers, software teams, graphic artists, project managers and the like. You can use your favourite software client to access our CVS and Subversion servers. Our basic or 'free' service is limited but we do offer commercial upgrades..."

  • SourceHosting.net: commercial Subversion hosting
    http://www.sourcehosting.net/

    "SourceHosting.net provides fully-managed Subversion hosting, as well as Bugzilla and CVS hosting packages. Hourly, secure offsite backups are included in all of our hosting plans, and add-on tools such as WebSVN and CVSweb are available as well."

  • wush.net: commercial Subversion hosting
    http://www.wush.net/

    "We provide professional quality Subversion hosting for individuals and small businesses. Our plans include a suite of integrated software designed to complement Subversion."

  • hosted-projects.com: commercial Subversion hosting
    http://www.hosted-projects.com/

    "svn-hosting.com provides professional Subversion hosting. We offer everything from small repositories to dedicated Subversion servers to provide you a stable backend for your critical work."

  • ProjectLocker: commercial Subversion hosting
    http://www.projectlocker.com/

    "ProjectLocker offers professional Subversion hosting, as well as additional development process, project management, and collaboration tools."

  • Gna!: free hosting for Projects under a GPL-compatible license
    https://gna.org/index.php

    "Gna! project [is] a central point for development, distribution and maintenance of Libre Software (Free Software) projects."

  • OpenSVN.csie.org: appears to be a free Subversion hosting site, with Trac service available too.
    https://opensvn.csie.org

    [We couldn't find a good description on the site. If you find one, let us know.]

  • http://www.projxpert.com/: professional software project hosting site
    http://www.projxpert.com/

  • DevGuard.com: commercial Subversion hosting
    http://www.devguard.com/

    "DevGuard.com offers commercial Subversion hosting for individuals and small businesses. Secure, encrypted data transfer, fast network access, easy to use web admin interface."

  • AVLUX Solutions: commercial Subversion hosting
    http://www.avlux.net/

    "full-service" web hosting, including (among other things) Subversion repositories and WebSVN.

  • GeekISP: commercial Subversion hosting
    http://www.geekisp.com/

    "GeekISP includes CVS and SVN repositories with all accounts."

  • TextDrive: commercial Subversion hosting
    http://textdrive.com/

    Repository hosting services, from shared hosting to fully managed dedicated server clusters.

  • Labyrinth Data Services: commercial Subversion hosting
    http://www.labyrinthdata.net.au/

    Australian-based Linux shell accounts and web hosting; unlimited Subversion repositories with all accounts.

  • SourceForge.net: no-charge hosting for open-source projects
    http://sourceforge.net/

    Probably the largest open source project hosting site on the Net.

  • hosted-projects.com: commercial Subversion hosting
    http://www.hosted-projects.com

    hosted-projects.com is a company specialized in web hosting services for software project teams offering the Subversion revision control system coupled with project and issue management software like Trac and Bugzilla.

  • google.com: free Subversion hosting for open source projects
    http://code.google.com/hosting/

    "Our new hosting service offers a collaborative development environment that includes: project workspaces with simple membership controls; version control via Subversion; issue tracking; mailing lists at groups.google.com."

  • myVersionControl.com: Subversion Hosting and Project Management
    http://www.myversioncontrol.com/

    Commercial Subversion hosting, integrated with other project management services.

  • Versionshelf.com: commercial Subversion hosting with free service for students and teachers
    http://www.versionshelf.com/

    Versionshelf has a streamlined webinterface to configure and access repositories, users, ACLs, rss feeds, external commit triggers, backups... easily. Access is always secured through 128-bit SSL data encryption.

  • Assembla: "... free workspaces with unlimited team size and integrated tools like wiki, discussion, alerts, Subversion and Trac."
    http://www.assembla.com/

Higher-level tools that use Subversion

Repository browsing tools

Miscellaneous Utilities

Miscellaneous Resources

Articles and Reviews



--
Happy day, happy life!
Posted by at No comments:

Wednesday, May 23, 2007

How to convert between string and byte array in c#?

 internal class EncryptionController
    {
        public static string Encrypt(string data)
        {
            try
            {
                byte[] bytes = Encoding.Unicode.GetBytes(data);
                return Convert.ToBase64String(bytes);
            }
            catch (Exception ex)
            {
                Exceptions.LogException( new Exception(string.Format("To encrpt the '{0}' data is failed!",data)));
                return null;
            }
        }
      
        public static string Decrypt(string encryptedData)
        {
            try
            {
                byte[] bytes = Convert.FromBase64String (encryptedData);
                return Encoding.Unicode.GetString(bytes);               
            }
            catch (Exception ex)
            {
                Exceptions.LogException(new Exception( string.Format("To dencrpt the '{0}' data is failed!", encryptedData)));
                return null;
            }
           
        }

    }

--
Happy day, happy life!
Posted by at No comments:
Subscribe to: Posts (Atom)