Thursday, February 25, 2010

Access Network Shared Drive using Command Prompt

In order to access the network shared drive from command prompt using the UNC path \\ServerName\ShareName we first need to map the drive to a drive letter and then use that drive letter in the same session on the command prompt.

Creating a network shared drive in a drive letter and then trying to access it by using the command prompt would not work as both are done in different sessions.

The other thing to take care is a network shared drive may require authentication which is usually done under the hood if you are in a network. So sometimes you might have to provide explicit authentication information.

In order to map the drive with a credential and to a drive we use

net use \\ServerName\ShareName /user:domain\username password && pushd \\ServerName\ShareName

For example to map a share on the server \\10.15.16.88\CertConfig
net use \\10.15.16.88\CertConfig /user:mydomain\anton.alfred mypassword && pushd \\10.15.6.88\CertConfig

In case you are logged in with a domain account which has credentials to login to the share you could just do

pushd \\ServerName\ShareName
or
pushd \\10.15.16.88\CertConfig

After this command you should get a message saying "The command run successfully" and the command prompt should show the drive letter we are in namely
Z:\>

Once this is done we can clean up if required by issuing the following command

DriveLetter:\> popd && net use ServerName\ShareName /delete
or
Z:\>popd && net use \\10.15.16.88\CertConfig /delete

In case you have not mapped the drive using net use you could just do

DriveLetter:\> popd
or
Z:\>popd

Labels:

Sunday, September 06, 2009

Isolated Storage for the Current User

Since Isolated storage is created using .NET you could use the SDK tool to manage this.

On a .NET framework path aware command prompt (administrator privileges in Vista) do the following

Clearing isolated storage for the current logged in user

storeadm /remove

Listing isolated storage for the current logged in user

storeadm /list


The storeadm.exe can be found in the .NET 2.0 SDK Tools/Bin Directory.

Happy Programming,
Anton

Labels:

Monday, August 24, 2009

RegFree COM Fix for Vista and XP

When using Registration Free COM, the requirement is to give a manifest with the executable so that the runtime loads the COM server dll from the location specified by the manifest.

This works fine if the COM server is not yet registered in the Registry. If its already registered then the OS first tries to load the registry location than the location specified in the manifest. To fix this issue Microsoft has released a hotfix for OSes that support Registry Free COM.


More info could be obtained from KB 843524.

This would part of the next service pack.

Happy Programming,
Anton

Labels:

Finding Assembly Target Environment

Using CorFlags.exe a managed or mixed (both managed and unmanaged) assembly together with target environment can be obtained.

Environment:
anycpu: PE = PE32 and 32BIT = 0
x86: PE = PE32 and 32BIT = 1
64-bit: PE = PE32+ and 32BIT = 0

Managed on top of the above you could use
ILONLY : 1

UnManaged
ILONLY : 0

Coreflags.exe can be opened from visual studio command prompt or if you have the framework SDK SDK Location\Bin folder

Happy Programming,
Anton

Labels:

Monday, December 01, 2008

Windows Vista 64 bit Memory Hog Problem ndis.sys BSOD

This problem is also caused by Microsoft Virtual Server 2005 R2 virtual network drivers.

The CPU shows 100 % utilization and the memory keep increasing till 98% at which the system freezes and you may get the BSOD or may have to forcefully restart. This does not occur in Safe mode as virtual drivers are not loaded in this mode.

This also doesn't occur all the time and may occur from time to time but quite frequently.

To solve this.
Install the 64 bit version of the update for Microsoft Virtual Server 2005 R2 SP1 (KB948515 )http://www.microsoft.com/downloads/details.aspx?FamilyId=A79BCF9B-59F7-480B-A4B8-FB56F42E3348&displaylang=en

Don't double click the file. Open a command prompt with admin privileges and type msiexec /p path of .msp file

Took me a while to find who is causing the problem as it doesn't appear all the time. One such tool is Process Explorer from Sys Internal which would identify which individual thread is causing the problem. Recommend this to be used for trouble shooting threads within a windows process as you usually get a svchost which doesn't give any information on the actual exe or dll.

Happy Debugging,
Anton

Labels:

Wednesday, November 12, 2008

Midnight Oil Saving tip for newbie Biztalk 2006 Developers

Unlike common .NET applications which stores the regenerated assembly in the bin folder. When you deploy the Biztalk Orchestration assembly to the Biztalk Server the assembly resides in the Global Assembly Cache.

So after deploying even if you change the orchestration and redeploy you won't see the change.

In order to reflect your change.
1. Completely Stop the Biztalk application
2. Re-Deploy the orchestration from Visual Studio.
3. Re-Start the Biztalk Instance
4. Re-Start the Biztalk application

If things dont work as expected.
1. Completely Stop the Biztalk application
2. Delete the entire Biztalk application (verify that this assembly is removed from GAC by viewing the assembly folder)
3. Re-Deploy the orchestration from Visual Studio.
4. Re-Start the Biztalk Instance
5. Create and enable ports
6. Re-Start the Biztalk application

I am not sure why this GAC thing is not communicated in most books... This would defintely give you a head start.

Happy Programming,
Anton

Labels:

Wednesday, August 06, 2008

Install or UnInstall a .NET 2.0 Windows Service

Open Visual Studio 2005 Command Prompt...

InstallUtil Assembly or Exe Name to install
InstallUtil /u Assembly or Exe Name to Uninstall

Happy Installing...
Anton

Labels:

Thursday, July 17, 2008

ASP.NET 2.0 Web Request Timeout - Configuring Long Running Web Request

In ASP.NET both a Web request (ASPX) pages together with Web Service Pages (ASMX) constitute a web request.

All web requests have a request timeout.

The ASP.NET script timeout (Request Timeout) also depends on the compilation node set in web.config.

When debug set to true

<compilation debug="true" />


The value for request timeout is 30,000,000 seconds (close to a year 31,536,000 Seconds)

This value is internal and can be found on the page init using


private int timeout = 0;


protected void Page_Init(object sender, EventArgs e)

{

timeout = Server.ScriptTimeout;

}

protected void Page_Load(object sender, EventArgs e)

{

Response.Write("Timeout:" + timeout);

}

When debug set to false

<compilation debug="false" />

The value for request timeout is 110 seconds

This value is config setting and can be found in machine level web.config (web.config.comments) under C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\CONFIG

<httpRuntime
executionTimeout = "110" [in Seconds][number]



With regard to the production environment the value should always be
<compilation debug="false" />

With regard to long running web request I have addressed these three scenarios

1. Long running Web Request Call
2. Web Request Call which in turn calls a long running Web Service Synchronously
3. Web Request Call which in turn calls a long running Web Service Asynchronously


Scenario:1 Long running Web Request Call
In order to make a longer web request call you need to override the <httpRuntime node and set the executionTimeout to a higher value depending on your need.

<httpRuntime
executionTimeout = "180" [in Seconds][number]


Setting present under system.web on the Web.config of the current application.

Scenario:2. Web Request Call which in turn calls a long running Web Service Synchronously
Since there are two applications involved here (one Web Application and the other Web Service Application) you need to increase the executionTimeout in both the applications web.config to a value equal to the longest time taken between them.


<httpRuntime
executionTimeout = "240" [in Seconds][number]


Now that we have increased the request time we now have to tell the web request page to increase the webproxy call time from the default 100 Seconds.

This is specified in the proxy created for the webservice


CalculatorService.CalculatorWS calculator;
calculator = new WebPlayground2005.CalculatorService.CalculatorWS();
calculator.Timeout = 190000 //milliseconds;


Scenario:3. Web Request Call which in turn calls a long running Web Service Asynchronously
Fortunately this is easier and require only the web.config of the web services application having an overide setting for

<httpRuntime
executionTimeout = "190" [in Seconds][number]


ASP.NET is clever enough to increase the web application request timeout till the asynchronous call is returned from the web service.

Happy Programming,
Anton

Labels: