After rebuilding my machine a few weeks ago, once again I find myself running into old problems and trying to remember how to repair them. This time, generating keys to strongly name my asesmblies through the Signing tab in Visual Studio 2008. I thought I would share it this time in case others have seen this problem...and struggled with it...
The Scenario:
For a Windows client application, open the Properties for the project, navigate to the Signing tab, check Sign the assembly and create a new key. In the Create Strong Name Key dialog, provide a new key name, provide a password, and click "OK".
The Problem:
An error message is presented: Create strong name key the operation could not be completed. Access is denied.
The problem repeats itself when I tried to use the strong name utility (sn.exe), with this error: Failed to generate strong name key pair. Access is denied.
The Solution:
I had to give my user account access to the key container in C:\Documents and Settings\All Users\Application Data\Microsoft\Crypto\RSA\MachineKeys. This is because you need to access the key store to create a strong name key. Modifying permissions did not work in my case, so I needed to reset the location of my key store. This can be done by opening the Visual Studio Command Prompt as an Administrator (right click on the start menu - run as Administrator). Reset the key store by typing the command:
sn.exe -c
How does it work?
Each container created using sn.exe -i is located in the MachineKeys directory (unless you specify elsewhere). The default key container that is used by sn.exe is also in that location.
In the event you reset your key container to a new one, and forget where it is...you can reset the key container for the strong name utility using sn.exe -c. So, if the account access fix doesn't work, you may be using an alternate key store so a reset may be in order.
I googled this topic a bit before writing this blog, and was surprised that very little has been written on this subject for a solution...furthermore...many people actually rebuilt their machines to solve the problem!!!! I hope this blog entry prevents a few more of those!!!
Wednesday, March 2, 2011
Friday, February 4, 2011
Volatile Keyword and Memory Barriers
The volatile keyword instructs the compiler to generate an acquire-fence on every read from that field, and a release-fence on every write to that field. An acquire-fence prevents other reads/writes from being moved before the fence; a release-fence prevents other reads/writes from being moved after the fence.
Intel’s processors always apply acquire-fences to reads and release-fences to writes — whether or not you use the volatile keyword — so this keyword has no effect on the hardware if you’re using these processors. However, volatile does have an effect on optimizations performed by the compiler and the CLR — as well as on 64-bit AMD. This means that you cannot be more relaxed by virtue of your clients running a particular type of CPU.
The effect of applying
Notice that applying volatile doesn’t prevent a write followed by a read from being swapped, and this can create brainteasers. Joe Duffy illustrates the problem well with the following example: if Test1 and Test2 run simultaneously on different threads, it’s possible for a and b to both end up with a value of 0 (despite the use of volatile on both x and y):
class MyVolatile
{
volatile int x, y;
void Test1() // Executed on one thread
{
x = 1; // Volatile write (release-fence)
int a = y; // Volatile read (acquire-fence)
}
void Test2() // Executed on another thread
{
y = 1; // Volatile write (release-fence)
int b = x; // Volatile read (acquire-fence)
}
}
The MSDN documentation states that use of the volatile keyword ensures that the most up-to-date value is present in the field at all times. This is incorrect, since as we’ve seen, Joe Duffy's example shows that a write followed by a read can be reordered.
Intel’s processors always apply acquire-fences to reads and release-fences to writes — whether or not you use the volatile keyword — so this keyword has no effect on the hardware if you’re using these processors. However, volatile does have an effect on optimizations performed by the compiler and the CLR — as well as on 64-bit AMD. This means that you cannot be more relaxed by virtue of your clients running a particular type of CPU.
The effect of applying
volatile
to fields can be summarized as follows:First instruction | Second instruction | Can they be swapped? |
---|---|---|
Read | Read | No |
Read | Write | No |
Write | Write | No (The CLR ensures that write-write operations are never swapped, even without the volatile keyword) |
Write | Read | Yes! |
Notice that applying volatile doesn’t prevent a write followed by a read from being swapped, and this can create brainteasers. Joe Duffy illustrates the problem well with the following example: if Test1 and Test2 run simultaneously on different threads, it’s possible for a and b to both end up with a value of 0 (despite the use of volatile on both x and y):
class MyVolatile
{
volatile int x, y;
void Test1() // Executed on one thread
{
x = 1; // Volatile write (release-fence)
int a = y; // Volatile read (acquire-fence)
}
void Test2() // Executed on another thread
{
y = 1; // Volatile write (release-fence)
int b = x; // Volatile read (acquire-fence)
}
}
The MSDN documentation states that use of the volatile keyword ensures that the most up-to-date value is present in the field at all times. This is incorrect, since as we’ve seen, Joe Duffy's example shows that a write followed by a read can be reordered.
Tuesday, January 11, 2011
Realtime log tracing with log4net using System.Console
I have a project that requires logging information to a text file (and possibly email at a later date). I decided to look into log4net as I heard many praises about the library. Within 15 minutes of reading the following tutorial by Tim Corey at CodeProject.com, I was able to start using the tool. Tim's article is a great "Quick Start" tutorial to get you up and running without fail.
http://www.codeproject.com/KB/dotnet/Log4net_Tutorial.aspx
There was one problem I found while fiddling with the project. When an error was logged, I needed to find and open the log file to view the error. What I needed was realtime output of the errors on the console. Tim, in his article shows how to log to the Output window using a ConsoleAppender, but he does not discuss how to view the errors in a console window for easy and obvious reading (nor does the log4net docs tell you how to do this - not that I found anyway).
I knew that there was a way to redirect output from the Output window (Output/Trace/Debug Window) to the System.Console. So I had to dust off a book from my bookshelf to come up with the an extremely simple way to provide realtime errors in your console applications. The code boils down to 2 lines shown here:
To make those lines work with log4net, it is required that you set up your app.config with a TraceAppender as follows:
That's all there is to getting realtime logging info in you console apps without the need to open log files or query your IDE. I find it useful for testing libraries that will eventually be included in a windows service.
Below is some sample code.
http://www.codeproject.com/KB/dotnet/Log4net_Tutorial.aspx
There was one problem I found while fiddling with the project. When an error was logged, I needed to find and open the log file to view the error. What I needed was realtime output of the errors on the console. Tim, in his article shows how to log to the Output window using a ConsoleAppender, but he does not discuss how to view the errors in a console window for easy and obvious reading (nor does the log4net docs tell you how to do this - not that I found anyway).
I knew that there was a way to redirect output from the Output window (Output/Trace/Debug Window) to the System.Console. So I had to dust off a book from my bookshelf to come up with the an extremely simple way to provide realtime errors in your console applications. The code boils down to 2 lines shown here:
TextWriterTraceListener myWriter = new TextWriterTraceListener(System.Console.Out); Debug.Listeners.Add(myWriter);
To make those lines work with log4net, it is required that you set up your app.config with a TraceAppender as follows:
<log4net> <root> <level value="DEBUG"/> <appender-ref ref="TraceAppender"/> </root> <appender name="TraceAppender" type="log4net.Appender.TraceAppender"> <layout type="log4net.Layout.PatternLayout"> <conversionPattern value="%-5level %logger - %message%newline" /> </layout> </appender> </log4net>
That's all there is to getting realtime logging info in you console apps without the need to open log files or query your IDE. I find it useful for testing libraries that will eventually be included in a windows service.
Below is some sample code.
public class TestWritingLogToConsole { private static readonly log4net.ILog log = log4net.LogManager.GetLogger(System.Reflection.MethodBase.GetCurrentMethod().DeclaringType); public TestWritingLogToConsole() { log.Info("You should see this text in a System.Console window."); } } public class Program { static void Main(string[] args) { TextWriterTraceListener myWriter = new TextWriterTraceListener(System.Console.Out); Debug.Listeners.Add(myWriter); System.Diagnostics.Trace.WriteLine("Trace Started."); TestWritingLogToConsole test = new TestWritingLogToConsole();
Console.WriteLine("End Program!"); Console.Read(); } }
Sunday, January 9, 2011
Virtual PC - Using Hard Disk 2
When you add a second hard disk to your Virtual PC, you may notice that the drive does not show in My Computer. The reason the drive is not recognized is because the volume has not been formatted. To format the drive open up the Computer Management console (Start >> Control Panel >> Administrative Tools >> Computer Management). When you click on Disk Management in the tree on the left, a wizard will pop up. Follow the instructions, noting that the new drive is called Disk 1 (the C: drive is Disk 0). Once the wizard is complete, right click on the new partition and select Add New Volume. Follow the instructions shown in the wizard and your second hard drive will be ready to use.
Saturday, January 8, 2011
Reactive Extensions
I've been researching Reactive Extensions and have found that the best tutorial I've encountered so far is at the site listed below. The "hands on lab" provides you with a sound foundation on which to build/design your own ideas. Here is the link
http://blogs.msdn.com/b/rxteam/archive/2010/07/15/rx-hands-on-labs-published.aspx
Search Google for "Reactive Extensions hands on lab" if the link above expires.
http://blogs.msdn.com/b/rxteam/archive/2010/07/15/rx-hands-on-labs-published.aspx
Search Google for "Reactive Extensions hands on lab" if the link above expires.
Friday, January 7, 2011
Subscribe to:
Posts (Atom)