Many times we needs to find how many instances of particular application or process are running.

This can be used in allowing to run only single instance of application or at most 2 etc.

Also count can be useful for licensing and other stuff.

So here is simple code to find out how many number of instances are running for particular application or process.

    string fileName = Process.GetCurrentProcess().MainModule.FileName;

    int count = 0;

    foreach (Process p in Process.GetProcesses())

    {

        try

         {

            if (p.MainModule.FileName == fileName)

            {

                count++;

            }

        }

        catch { }

    }

    MessageBox.Show("Total Instances Running are " + count);

If you want to do anything additional to this and not aware how to do then please post comment and wait for reply !!!

To achieve the same we can use Take and Skip Partition Operator of LINQ.

Skip Partition Operator Reference: http://msdn.microsoft.com/en-us/library/bb358985.aspx

Take Partition Operator Reference: http://msdn.microsoft.com/en-us/library/bb503062.aspx

For this we will consider following example of Array Collection.

Above example is very simple to understand, we have applied Take and Skip Partition Operator to fetch partial result set.

If you have any queries, regarding the same, please lets me know.

We have developed many windows application using C# or VB.NET.

In that we stored connection string and other required data in ‘app.config’ file, and we modify that file using our application to store latest connection or other information.

This is standard practice and works as well.

But in ‘Windows 7’ OS architecture is changed in teams of security and other features.

So we can’t modify files which are in % program file % application directory %.

There are there options, run application as administrator. We can run it as admin, but we can’t guarantee that all of our customer will !!!

Other option is keep it same, means write in app.config which will be there in program files.

It will work as desired but ‘content will not be modified in config file from program files’, this is due to one feature of windows 7 called as ‘Common file and registry virtualization’

Whatever you modify in app.config or program files, it will be get modified in virtual file which stored in ‘%userprofile%\AppData\Local\VirtualStore’. And when you try read app.config, it will be read from virtual space rather from program files.

There is no harm with this approach, but you will have to delete the virtual file when you uninstall the application.

The other and safe way for this issue is to use ‘application data’ space of windows OS. All the major applications including word, outlook stores there data in app data.

So it is good habit to store your data there.

A comprehensive coding standard is essential for a successful product delivery. The standard helps in enforcing best practices and avoiding pitfalls, and makes knowledge dissemination across the team easier. The C# coding standard presented here is very thin on the “why” and very detailed on the “what” and the “how.” The coding standard presented next captures best practices, dos and don’ts, pitfalls, guidelines, and recommendations, as well as naming conventions and styles, project settings and structure, and framework specific guidelines.

Standard Coding Practices in .NET

·         Avoid putting multiple classes in a single file. 

·         A single file should contribute types to only a single namespace. Avoid having multiple namespaces in the same file.

·         Avoid files with more than 500 lines (excluding machine-generated code).

·         Avoid methods with more than 200 lines.

·         Avoid methods with more than 5 arguments. Use structures for passing multiple arguments.  

·         Lines should not exceed 120 characters.

·         Do not manually edit any machine-generated code. 

    o   If modifying machine generated code, modify the format and style to match this coding standard.

    o   Use partial classes whenever possible to factor out the maintained portions.

·         Avoid comments that explain the obvious. Code should be self-explanatory. Good code with readable variable and method names should not require comments.

·         Document only operational assumptions, algorithm insights and so on.  

·         Avoid method-level documentation.

    o   Use extensive external documentation for API documentation.

    o   Use method-level comments only as tool tips for other developers.

·         With the exception of zero and one, never hard-code a numeric value; always declare a constant instead. 

·         Use the const directive only on natural constants such as the number of days of the week. 

·         Avoid using const on read-only variables. For that, use the readonly directive.

·         Assert every assumption. On average, every fifth line is an assertion.

·         Every line of code should be walked through in a “white box” testing manner. 

·         Catch only exceptions for which you have explicit handling.

·         In a catch statement that throws an exception, always throw the original exception (or another exception constructed from the original exception) to maintain the stack location of the original error:

Catch (Exception exception)

{   

   MessageBox.Show(exception.Message);

   throw;

}

·         Avoid error codes as method return values. 

·         Avoid defining custom exception classes.

·         When defining custom exceptions:

   o   Derive the custom exception from Exception.

   o   Provide custom serialization. 

·         Avoid multiple Main () methods in a single assembly.

·         Make only the most necessary types public, mark others as internal.

·         Avoid friend assemblies, as they increase inter-assembly coupling.

·         Avoid code that relies on an assembly running from a particular location.

·         Minimize code in application assemblies (EXE client assemblies). Use class libraries instead to contain business logic.

Advantages of Transport level security

• Does not need any extra coding as protocol inherent security is used.
• Performance is better as we can use hardware accelerators to enhance performance.
• There is lot of interoperability support and communicating clients do not need to understand WS security as it’s built in the protocol itself.

Disadvantages of Transport level security

• As it’s a protocol implemented security so it works only point to point.
• As security is dependent on protocol it has limited security support and is bounded to the protocol security limitations.

Advantages of Message level security

• Provides end to end security as it’s not dependent on protocol. Any intermediate hop in network does not affect the application.
• Supports wide set of security options as it is not dependent on protocol. We can also implement custom security

Disadvantages of Message level security

• Needs application refactoring to implement security.
• As every message is encrypted and signed there are performance issues.
• Does not support interoperability with old ASMX webservices

Across all service bindings there are five possible security modes:

• None. Turns security off.
• Transport. Uses transport security for mutual authentication and message protection.
• Message. Uses message security for mutual authentication and message protection.
• Both. Allows you to supply settings for transport and message-level security (only MSMQ supports this).
• TransportWithMessageCredential. Credentials are passed with the message and message protection and server authentication are provided by the transport layer.
• TransportCredentialOnly. Client credentials are passed with the transport layer and no message protection is applied

Within the Windows Communication Foundation programming model, bindings are represented by the System.ServiceModel.Channels.Binding class. All binding classes must derive from this base class.

Following are the different bindings provided by WCF by default:

1. BasicHttpBinding

2. WSHttpBinding

3. WSDualHttpBinding

4. WSFederationHttpBinding

5. NetTcpBinding

6. NetPeerTcpBinding

7. NetNamedPipesBinding

8. NetMsmqBinding

9. MsmqIntegrationBinding

10. CustomBinding

The choice of client credential type depends on the security mode in place. For transport security you can require a Windows credential or certificate-and there are variations on how Windows credentials are passed via TCP, HTTP and MSMQ. Message security supports any of the following settings for clientCredentialType:

• None
• Windows
• UserName
• Certificate
• IssuedToken

You can set anyone of above as clientCredentialType in web.config as shown below:

  <wsHttpBinding>

    <binding name="wsHttp">

      <security mode="Message"> 

        <message clientCredentialType="UserName" />

      </security>

    </binding>

  </wsHttpBinding>

Message security uses the WS-Security specification to secure messages. The specification describes enhancements to SOAP messaging to ensure confidentiality, integrity, and authentication at the SOAP message level (instead of the transport level).

In brief, message security differs from transport security by encapsulating the security credentials and claims with every message along with any message protection (signing or encryption). Applying the security directly to the message by modifying its content allows the secured message to be self-containing with respect to the security aspects. This enables some scenarios that are not possible when transport security is used.