Free Ebook: Under the Hood of .Net Memory Management

Under the Hood of .Net Memory Management 2 Part book

http://www.reflector.net/2012/03/grab-free-copy-%E2%80%9Cunder-hood-net-memory-management%E2%80%9D/

http://www.red-gate.com/products/dotnet-development/ants-memory-profiler/learning-memory-management/memory-management-gotchas

Troubleshooting:Database diagram support objects cannot be installed because this database does not have a valid owner

The fix for this issue is described in following link

http://blog.sqlauthority.com/2012/02/06/sql-server-error-fix-database-diagram-support-objects-cannot-be-installed-because-this-database-does-not-have-a-valid-owner/

I know the content of above link will never disappear, still here is the copy of the content from the above link

Error:
Database diagram support objects cannot be installed because this database does not have a valid owner. To continue, first use the Files page of the Database Properties dialog box or the ALTER AUTHORIZATION statement to set the database owner to a valid login, then add the database diagram support objects.

Workaround / Fix / Solution :

Well for a while I attempted few things and nothing worked. After that I carefully read the error and I realized that solution was proposed in the error only. I just have to read it carefully. Here are the steps I did to make this work.

-- Replace YourDatabaseName in following scriptALTER AUTHORIZATION ON DATABASE::YourDatabaseName TO sa
GO

• Select your database >> Right Click >> Select Properties
• Select FILE in left side of page
• In the OWNER box, select button which has three dots (…) in it
• Now select user ‘sa’ or NT AUTHORITY\SYSTEM and click OK.

This should solve your problem.

Please note, I suggest you check your security policies before changing authorization. I did this to quickly solve my problem on my development server. If you are on production server, you may open yourself to potential security compromise. 

Troubleshooting : HTTP could not register URL http://+:8080/AppName/ServiceName/ because TCP port 8080 is being used by another application.

Reference URL :

http://saravananarumugam.wordpress.com/2011/03/25/http-could-not-register-url-http80temporary_listen_addresses634f73f6-c612-4441-acf8-79ddd5c62f98-because-tcp-port-80-is-being-used-by-another-application/

http://saravananarumugam.wordpress.com/2011/03/01/http-could-not-register-url/

-------------------------------------------------
Content From above URLs
----------------------

Article1

When I used a Duplex channeled binding (wsDualHttpBinding), during the run time I received the following exception.

Exception:

HTTP could not register URL http://+:80/Temporary_Listen_Addresses/634f73f6-c612-4441-acf8-79ddd5c62f98/ because TCP port 80 is being used by another application.

This is because the port 80 is being used by the IIS (the default web site uses Port 80) and the callback from the service attempts to register the same port for communication.

Solution:

The solution to this is to instruct the WCF to use a different port. I had to add the following binding configuration.

    <bindings>

      <wsDualHttpBinding>

        <binding name="wsDualHttpBinding_IGreetingService" 

         clientBaseAddress="http://localhost:8088/clientCallbackUrl">

        </binding>

      </wsDualHttpBinding>

    </bindings>

I also had to specify the bindingConfiguration in endpoint to point to this.

<endpoint address="ws" binding="wsDualHttpBinding" 

contract="DuplexChannel.IGreetingService" 

bindingConfiguration="wsDualHttpBinding_IGreetingService"/>

But unfortunately specifying the clientBaseAddress in service configuration doesn’t take part in the WSDL. As a result clientBaseAddress won’t show up in the client side config. There is no negotiation happening during the runtime either.

So instead of providing the clientBaseAddress in the service side, create the proxy and config as usual and then provide the clientBaseAddress by modifying the client side configuration.

As a result, the client side configuration should typically be looking like this.

<configuration>

    <system.serviceModel>

        <bindings>

            <wsDualHttpBinding>

              <binding name="WSDualHttpBinding_IGreetingService"

                 clientBaseAddress="http://localhost:8088/clientCallbackUrl">

                <security mode="Message">

                  <message clientCredentialType="Windows" 

                          negotiateServiceCredential="true"

                      algorithmSuite="Default" />

                </security>

              </binding>

            </wsDualHttpBinding>

        </bindings>

        <client>

            <endpoint address="http://localhost:54927/GreetingService.svc/ws"

                 binding="wsDualHttpBinding" 

                 contract="GreetingService.IGreetingService"

                 bindingConfiguration="WSDualHttpBinding_IGreetingService"

                 name="WSDualHttpBinding_IGreetingService">

                <identity>

                    <userPrincipalName value="xxx\xxxx" />

                </identity>

            </endpoint>

        </client>

    </system.serviceModel>

</configuration>

Note: By default the Visual Studio would not be able to register even http://localhost:8088/clientCallbackUrl if it is used for the first time due to security constraints.

Refer to HTTP could not register URL for further detail.

An alternate solution to using netsh command is to run the Visual Studio itself in Administrator mode.

Article 2

From here on, I am going try to publish the exceptions/error messages I encounter during the programming and their corresponding resolution.

Exception

I wrote a self host in Visual Studio 2005 in Windows XP. It worked fine.

namespace CalculatorHost

{

    class Program

    {

        static void Main(string[] args)

        {

            ServiceHost host = new ServiceHost(typeof(CalculatorService), 

                new Uri[] { new Uri("http://localhost:8080/Calculator") });

            host.AddServiceEndpoint(typeof(ICalculatorService), 

                new BasicHttpBinding(), "");

            ServiceMetadataBehavior behavior = 

                new ServiceMetadataBehavior();

            behavior.HttpGetUrl = new 

                Uri("http://localhost:8080/CalculatorService/Meta");

            behavior.HttpGetEnabled = true;

            host.Description.Behaviors.Add(behavior);

            host.Open();

            Console.WriteLine("Calculator Service Started!!!"+

                "\nPress enter to stop the service");

            Console.ReadLine();

            host.Close();

        }

    }

}

I tried to execute the same program in Visual Studio 2010 in Windows 7. But it gave the following exception.

HTTP could not register URL http://+:8080/CalculatorService/Meta/. Your process does not have access rights to this namespace (see http://go.microsoft.com/fwlink/?LinkId=70353 for details).

Note: I received the same exception for http://localhost:8080/Calculator as well.

Solution

The exception itself has offered helping hands on how to register Http Namespace by saying(seehttp://go.microsoft.com/fwlink/?LinkId=70353 for details).

It takes us to the Microsoft’s title “Configuring HTTP and HTTPS”. The exception above resolved by following the solution under “Configuring Namespace Reservations”.

I ran the following command under the .Net Command Prompt.

C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC>netsh http add urlacl url

=http://+:8080/CalculatorService/Meta/ user=\Everyone

Url reservation add failed, Error: 5

The requested operation requires elevation (Run as administrator).

I didn’t get through it yet, because by default the .Net command prompt doesn’t have access to register the Http Namespaces.

I reran the .Net command prompt in Administrator mode (Right Click the .Net Command Prompt in Start Menu, and select Run as Administrator).

The same command worked well in Administrator mode.

C:\Windows\system32>netsh http add urlacl url=http://+:8080/CalculatorService/Me

ta/ user=\Everyone

URL reservation successfully added

Another simple alternate to using netsh http command is to run the Visual Studio itself in Administrator mode.

Note: netsh is useful for a verity of work. Refer the following pages for more detail.

Netsh Command Reference

Netsh Commands for Hypertext Transfer Protocol (HTTP)

Understanding the error message: “Login failed for user ''. The user is not associated with a trusted SQL Server connection.”

Reference URL 

http://blogs.msdn.com/b/sql_protocols/archive/2008/05/03/understanding-the-error-message-login-failed-for-user-the-user-is-not-associated-with-a-trusted-sql-server-connection.aspx

Please check the Article content:

Understanding the error message: “Login failed for user ''. The user is not associated with a trusted SQL Server connection.”

This exact Login Failed error, with the empty string for the user name, has two unrelated classes of causes, one of which has already been blogged about here:http://blogs.msdn.com/sql_protocols/archive/2005/09/28/474698.aspx.  In addition to an extra space in the connection string, the other class of causes for this error message is an inability to resolve the Windows account trying to connect to SQL Server.  This list is not intended to be exhaustive, but here are several known root causes for this error message. 

1)      If this error message occurs every time in an application using Windows Authentication, and the client and the SQL Server instance are on separate machines, then ensure that the account which is being used to access SQL Server is a domain account.  If the account being used is a local account on the client machine, then this error message will occur because the SQL Server machine and the Domain Controller cannot recognize a local account on a different machine.  The next step for this is to create a domain account, give it the appropriate access rights to SQL Server, and then use that domain account to run the client application.  Note that this case also includes the special accounts “NT AUTHORITY\LOCAL SERVICE” and “NT AUTHORITY\NETWORK SERVICE” trying to connect to a remote SQL Server, when authentication uses NTLM rather than Kerberos.

One very common case where this can occur is when creating web applications with SQL Server and IIS; often, the web page will work during development, then errors occur with this message after deploying the web site. This occurs because the developer’s account has access to SQL Server, but the account IIS runs as does not have access.  To fix this specific problem, refer to this kb article about impersonating a domain user in ASP.NET: http://support.microsoft.com/kb/306158

2)      Similar to above: this error message can appear if the user logging in is a domain account from a different, untrusted domain from the SQL Server’s domain.  The next step for this is either to move the client machine into the same domain as the SQL Server and set it up to use a domain account, or to set up mutual trust between the domains.  Setting up mutual trust is a complicated procedure and should be done with a great deal of care and due security considerations.

3)      This error message can appear immediately after a password change for the user account attempting to login.  This occurs because of caching of the client user’s credentials.  The next step here is to log out the application user with the old password, and re-login with the new password before running the application.

4)      If this error message only appears sporadically in an application using Windows Authentication, it may result because the SQL Server cannot contact the Domain Controller to validate the user.  This may be caused by high network load stressing the hardware, or to a faulty piece of networking equipment.  The next step here is to troubleshoot the network hardware between the SQL Server and the Domain Controller by taking network traces and replacing network hardware as necessary.

5)      This error message can appear consistently for local connections using trusted authentication, when SQL Server’s SPN is not interpreted by SSPI as belonging to the local machine.  This can be caused either by a misconfiguration of DNS, or by a machine having multiple names.  If your machine has multiple names, try to work around the need for multiple names and give it a unique name.  If the machine just has one name, then check your DNS configuration.