Earlier today a friend was trying to invoke GetAuditRules API on a file using c# code, but it was always returning a count of 0 inspite of having set a specific audit rule on the file via windows explorer. The surprising part was that GetAccessRules API was working and the code was running locally so it had full security rights as well.
What do we do when we want to do something which we haven’t done before? Basic instinct of a developer says that Google and this is what I did. And what was i trying? Write a unit test case to compare two objects for equality. By equality here, I mean similarity of data present int he objects.The objects I had to compare had sub-objects, properties as lists and the usual primitive data type properties. Unfortunately .Net doesn't have any API which compares object for equality.
When writing trivial get/set type properties, I have seen many developers still struggle during debugging since if they do a step into (typically F11), they end up going into the getter and setter methods as well.
Debugger related attributes have been available since early times, but somehow people seem unaware. Typically one can use DebuggerHidden or DebuggerStepThrough attributes, as shown in the following code snippet.
There will be probably very few out there who haven't heard about Reflector and don't use it. Earlier today I noticed this blog that mentioned Red gate acquiring Reflector. I proceed to the mentioned site. I noticed that the latest version if 5.1.3 and I had 5.1.1. so I clicked the "Download your free copy now!" button.
Interestingly the tool may still be free, but laying your hands on it isn't that easy anymore. You are now required to register to download. This is a bit of a damper. I will eventually register and download the latest, but having to register to get the freely available tool earlier !! I don't like it.
ASP.NET AJAX is come a long way since its inception a few years back and my personal take it is that it in a hype cycle right now, where everyone is trying to jump on-board and create AJAX based applications. Needless to say that it has its own benefits, but there definite downsides to it as well. You can read a set of 10 important aspects around AJAX here.
It is known that though it gives a flicker free UX, the under-the-hood story tells a different tale. Having read about it, some days back, we did a small experiment to really see the kind of differences one can get with different approaches and you can read about our findings in this report (Download file). The scenario we took is very simplistic, but the results are still eye-opening.
I have played around a bit with MSMQ private queues and documented some of my findings earlier. In my first blog on this topic, I had captured how the naming of the queue is critical to connect to the right queue.
If it was local private queue, you could use - ".\\private$\\queuename"
and if it was remote private queue, you use - "FormatName:Direct=OS:machinename\\private$\\queuename"
In one of our internal forums, recently, someone had posted a query regarding issues in connecting and receiving messages from journal queues. The exception they were getting was "Queue ID is not registered in DS". I hadn't worked with Journal queues before, but this error seemed to me to be related to the queue path.
In my earlier blogs (here and here), I had discussed about the importance of specifying the right name for the queue and also mentioned how the path will typically look like. I decided to give it a try and created a private queue on my local machine and enabled journaling on it. Enabling journaling is as trivial as checking a checkbox in the queue property window. You can also enable it by setting the UseJournalQueue property on the message.
Recently a colleague of mine shared a code that he was working on where he was playing around with Asynch ADO.NET. He had a simple WinForm application. On the click of a button, he was making calls to the DB to get data. To try out the asynch features, he had introduced delays in the code.
Further to my unit testing experiments that I have been blogging about in the last few days, I was playing around with the DashCommerce starter kit. After installing and configuring the site, I started by creating some tests for the code in the App_code folder.
The test creation was successful and I was all set to run. But luck was against me and I got compilation errors regarding missing namespace. As I had mentioned in my earlier blog, the testing happens via private accessor and since its creation happened successfully, ideally I shouldn't have had a need for adding explicit references and namespaces to my test project.
In my previous blogs (here and here), I have been discussing about unit testing on an ASP.NET web site that is hosted on IIS. While doing the work on that, I also had a need to debug my test case. The documentation on MSDN talks about putting break points and attaching to w3wp process and then debug the tests.
This however didn't work for me on VS 2008. What worked was adding the System.Diagnostics.Debugger.Break() call in my code and then running the tests like normal. When the code hit the Debugger.Break line, it asked me, which debugger to use and I selected the already open VS 2008 instance and it took me to the correct line of code and i was able to debug.
In my previous blog I had mentioned about the issue in generating private accessors for ASP.NET code that is hosted on IIS. Does this mean that we can't test the web site if hosted on IIS?
You can, but it will be a bit more complex and you may not be able to cover all scenarios. The idea is to work with the PrivateObject that is available from the test context. In the previous blog, I had talked about a web site with a Calculator class in the App_Code folder that i wanted to test. Let's continue with the same example.
I was recently trying to dirty my hands on using the Unit test framework that comes with Visual Studio. I decided to give it a try on my newly installed VS 2008. I created a pretty trivial ASP.NET site hosted on IIS with a Calculator class that I put in App_Code folder and generated the tests.
One of the key differences in working with Unit test framework for ASP.NET as compared to other projects like Winform or Class library is that the code in ASP.NET gets compiled dynamicall into various assemblies and hence we can't bind to a specific assembly upfront. Check more details on this here.
During a recent project, we had need for querying and working with Active Directory. Searching on net, gave lots of help, but most were around creating and managing users. Our need was simple - to get some user specific details from AD.
The trickest part of working with AD is the AD structure and what properties have been defined and hence available for querying. Without really knowing this, one can continue to grop in dark for long hours without much success.
BizTalk 2006 R2 provides in-built support to access and work with WCF based services. To get more detailed understanding of BizTalk Server 2006 R2, you may want to read "Introducing Microsoft BizTalk Server 2006 R2". In case you want to work with the WCF LOB Adapter SDK, you can get it here.
However you may still be using BizTalk Server 2004 or even the pre-R2 BizTalk Server 2006 version and may still want to work with WCF. In this article, we have provided details on how to go about doing it. Comments about the article are welcome !
For some work I was doing with BizTalk 2006, I had used reflection and played around with internals of BizTalk Assembly. With BizTalk 2006 R2 now available, I decided to give the code I was working then, a try again.
I have earlier blogged about installing BizTalk 2006 R2 on my Vista machine and as part of that I had built the CallOrchestartion SDK Sample. I decided to work with this sample code itself.
The other day a colleague asked about how to provide information for the "User" column in the Event log. The EventLog.WriteEntry method has various overloads, but none that allows you to pass the user details.
There is an EventLogEntry class also that .NET provides, which has a UserName member, but it is read only property and is used to query event entries from the log. This means that by using .NET APIs there isn't a way to provide the user name for event log entries.
To ensure optimum application performance in terms of throughput and processing speed, performance tuning can play a critical role. However, it could entail risks and unforeseen costs without the right approach. In order to reduce risks and costs, performance tuning should be treated as an integral part of a project life cycle. In most projects, however, it is conducted during the final stages of testing or when customers complain about performance post production deployment.
Performance tuning of .NET 2.0 applications can be achieved using Visual Studio 2005 tools. In this paper, I explore these tools and also provide guidelines on how to use them.
[Updated: 28th January 2008] This and other Infosys papers/handbooks on MS technologies can be found here.
In my earlier blog I had discussed about creating a new AppDomain. You may have a need to track the loading of assemblies in this newly created AppDomain. AppDomain class provides an event for this purpose called AssemblyLoad. However when I tried to work with it, I never got the event to fire up.
The catch is that the event handler needs to be static. When I had added the event handler via VS 2005 by using the tip that appears once you type "+=" after an event, it added the event handler as private void and missed the "static" qualifier. Due to this the event handler was not getting called. Once I added this, it started to work like a breeze. The handler signature will look something like the following
static void domain_AssemblyLoad(object sender, AssemblyLoadEventArgs args)
//add code to handle assembly load event here
We all have read that AppDomains are light weight processes that .net uses to run applications, but I hardly ever played with AppDomains directly. Recently I decided to give this a try and following are my findings. If you want to get more information on AppDomains, check this excellent blog by Chris Brumme.
Sometime back I had blogged about how to send messages to remote private queues. There were a few queries on how to read from remote queue as well.
To me it should have worked by using the MessageQueue.Receive API instead of .Send. I decided to give this a try anyway and it indeed is as trivial as that. However a few things to take care while trying to get this working.
Earlier today someone asked me where are the project properties of ASP.NET 2.0 web site stored? This seemingly simple question proved lot more difficult to answer since there is no .CSPROJ file for the web site (I was working with C# and hence .CSPROJ).
I started by creating a new ASP.NET 2.0 Web site project (you can create this on HTTP or file system, the behavior is the same). After that I went to the project properties dialog and modified a few properties like in Start action group, I modified Specific page to some value dummy value and in the Server group I modifed to point to some custom server. Do note that the custom server option can't be set if you created the web site on HTTP.
The other day a colleague asked if there was a way he could work with different versions of the same assembly in his code i.e. could he invoke say Method A on Version 1.0 and Method B on Version 2.0 of the same assembly?
I was initially surprised as to why he would want to do that? People ask about being able to automatically load newer version of the assembly with the application or in case of .net being able to load an assembly built with .net framework 1.1 in an application built with .net framework 2.0, but usually not this.
We had some interesting discussions internally, post my earlier blog on 250 threads/CPU. There are some confusions also on default values and what comes from thread pool etc. I spent a little bit more time on basics and document them.
The ThreadPool contains threads marked as worker threads and IO threads (completion ports). The default max value for these are 25 threads / per process / per CPU. The default min values for these is #CPU, so on a single CPU machine it will be 1.
Recently while working on a project, I came across an interesting behavior of Assembly.Load method and its different overloads. I specifically tried with Assembly.Load(AssemblyName) and Assembly.Load(string) overloads.
My testing showed that the overload that accepted a string depended on the value of Environment.CurrentDirectory. Usually when using Assembly.Load method, one would expect the assembly to be loaded from the application's root folder.
When working with multi-threaded applications, we all know that we should usually try and work with the ThreadPool class as the first option. In case we have a case where the work done by a thread is long (couple of seconds), we should then look at creating a new thread to avoid starving threads from the pool and behave like a good .net managed citizen.
However there have been issues with this due to the limit of 25 threads/CPU with .NET 1.1, especially for web based applications. The default limit for minimum threads was also set to be equal to #CPU. Note only this caused lot of contention issues, but also required people to play around with the values in the ASP.NET configuration files.
Recently a friend was facing issues in sending messages to a private msmq queue on a remote machine. I had worked on this about 4-5 years back and I recalled that I was able to work with remote private queues. So I decided to give it a try again.
Following are things that I found.
Working with anonymous methods can be a bit confusing and also make the code a bit difficult to read. Recently a colleague of mine, Vinay, however showed another interesting class and method naming convention.
The other day a friend, having read my earlier blog on Settings in .net fwk 2.0 asked me a question about user settings. He had built an application where he was dealing with user settings and though he was getting the required behavior of user settings getting updated everytime he changed some value and using the new value on next load of the application also, but the mystery was he wasn't able to locate where the values were being saved?
I decided to look into this and created a small windows application which had a text box to input new values, a button to assign them and another button whose text would get updated based on the value in the text box. This value, I also storted as user settings by calling Setting.Default.Save(). I ran the application, set a new text and hit the update button and closed the application. When I ran the application again, I did see the button displaying the new value i had assigned in my previous run.
I recently came across this nice article on how to get the UAC elevation request working for our own applications in Vista. There are however one or two additional observations that I wanted to capture.
First is that the behavior is seen when directly executing the application. If you compile and debug via VS2005, you won't see the elevation request poping up. Additionally, if you run your VS2005 as Administrator, then the application will also run in that mode and hence the label will display "Yup".
The other observation is that if you disable the UAC via control panel for your login, the elevation request popup won't occur when you run the application (outside of VS also) or for any other application for that matter. This is also indicated by a regular icon for the application and the security shield is no longer visible.
We all know that when working with Winform applications and threads, we need to be careful about accessing the UI controls. These controls are meant to be accessed only on the thread that built them, which in this case is the primary application thread.
In multithreaded applications, when additional threads are used to perform background jobs to ensure that the UI remains responsive, one has to be careful about updating the controls on the form. There are articles already, that talk about how to address this problem. Check here.
Working with Configuration files in .net fwk 1.1 was additionally supported by the Configuration block available as part of Enterprise Library (EL). With the release of .net fwk 2.0 and the introduction of System.Configuration subsystem, this is now becoming the way to work with configuration files. Hence EL 2.0 doesn't include a new Configuration block any more. Check this.
Working with System.Configuration via the Settings is quite simple with Visual Studio (VS) 2005. Check this article in case you need to know how to go about using it.