Navigation

Search

Categories

On this page

Thousands Separator When Formatting Numeric String in .NET (C#, VB.NET) Programming
AD Groups Must Have "Global" Scope to be handled properly by WSS and Reporting Services in TFS
Download WebService Studio 2.0
VS 2008: Windows SDK 6.0 Needed for WCF "Service Configuration Editor" Utility
How Windows Performance Counters of "Average" Types Linked to Their Bases
Where Are the Third-Party ASP.NET Theme/Skin Galleries?
Microsoft "Acropolis" six years too late. I liked CCmdTarget of MFC back in nineties.
.NET API for Programmatic MP3 Tag (ID3v1 and ID3v2) Access and Modifications
MSI-based setup packages custom actions made in Visual Studio may not work correctly in upgrade mode

Archive

Blogroll

Disclaimer
The opinions expressed herein are my own personal opinions and do not represent my employer's view in anyway.

RSS 2.0 | Atom 1.0 | CDF

Send mail to the author(s) E-mail

Total Posts: 48
This Year: 15
This Month: 0
This Week: 0
Comments: 8

Sign In
Pick a theme:

 Saturday, July 26, 2008
Saturday, July 26, 2008 10:18:35 AM (Eastern Standard Time, UTC-05:00) (  |  |  |  )

It's much easier to read large numbers when thousands are separated by commas. But I can never remember how the numeric format with thousands comma-separated is defined for .NET String.Format() method and for the databinding. So more as a note to self, here it is:

string output = string.Format("{0:#,#}", 123456789); // Will produce 123,456,789

The same goes for data binding data sources to data controls like DataGridView. Specify format as "{0:#,#}".

Comments [0] | | # 
 Friday, July 11, 2008
Friday, July 11, 2008 4:22:14 PM (Eastern Standard Time, UTC-05:00) (  |  |  )

I went through the exercise of setting up Microsoft Team Foundation Server 2008, and needed to do group-level-only rights assignment, so that IT folks could manage security by simply moving people in and out of the Active Directory groups to grant/revoke TFS access rights, instead of setting up individual user rights in TFS, Windows Sharepoint Services and Reporting Services. Initially I created some groups for TFS with the "Domain local" scope, which allowed me to nest other, "Global", groups in them. But I noticed that with WSS and RS, assigning rights to "Domain local" groups does nothing - WSS and RS act as users are not members of the group, while TFS services were working properly. I had to re-create AD groups and make them of "Global" scope to make WSS and RS working properly.

Comments [0] | | # 
 Monday, May 19, 2008
Monday, May 19, 2008 9:32:03 AM (Eastern Standard Time, UTC-05:00) (  |  |  )

WebService Studio 2.0 (a.k.a. Web Service Studio) is a quick & dirty web service client tool that can import your web service's WSDL and allow you to call web service's methods without having to create your own test client.

WebService Studio used to be hosted on Microsoft's GotDotNet web site, but ever since GotDotNet was replaced by Codeplex, Web Service Studio was nowhere to be found. Fortunately, some kind stranger made WSS available for download at his blog: http://mattharrah.com/blog/web-tools/net-web-service-studio-20/.

Update: BTW, if you are planning to use WebService Studio to test WCF web services, you will need to configure your web service to use basicHttpBinding instead of wsHttpBinding.

Comments [0] | | # 
 Thursday, May 15, 2008
Thursday, May 15, 2008 3:53:38 PM (Eastern Standard Time, UTC-05:00) (  |  |  |  )

After installing Visual Studio 2008 on a new machine and starting playing with a simple Windows Communication Foundation project, I attempted to change service's WCF settings using WCF Service Configuration Editor utility (SvcConfigEditor.exe). However, I got the "Windows SDK is not installed correctly" error. "Internets" were surprisingly mum on the subject, so I had to figure out the solution myself.

To fix the problem, I had to install Windows SDK 6.0 manually. After I did that, the problem went away. Just quit Visual Studio 2008 before installing Windows SDK.

Update: Even after reinstalling Windows SDK, first time right-clicking on the web.config in the Visual Studio '08 Solution Explorer does not bring "Edit WCF Configuration" item to the menu. However, after I did Tools | "WCF Service Configuration Editor", "Edit WCF Configuration" item started showing up upon right-clicking the .config file.

Comments [0] | | # 
 Thursday, March 20, 2008
Thursday, March 20, 2008 5:04:21 PM (Eastern Standard Time, UTC-05:00) (  |  |  |  )

Some time ago I added performance counters to the application I was working on, and for some inexplicable reason all counters of "Average" type, like AverageCount64 or AverageTimer32, didn't work at all, always having 0 value. Then I had no time to find out why it was not working, but today I did. As you may know, "Average" counters are made of two distinct counters: the base counter and the average counter itself. The mystery was that by looking at all the samples returned by Google, it was unclear how the Base and the Average itself are linked together. It looked like you create the Base and the Average, add them to the collection and somehow magically Windows figures they need to be linked together when averages are calculated. After some research it looks like the two are linked by counter name! It appears that base's name should be the name of real counter, plus word " base". For example, when you define your counter category that has average performance counter, you do something like this:

   counters.Add(
new CounterCreationData("whatever", "whatever desc", PerformanceCounterType.AverageCount64));
   counters.Add(new CounterCreationData("whatever base", "whatever base desc", PerformanceCounterType.AverageBase));

To my surprise, changing the "whatever basevalue of the counter name in both CounterCreationData and PerformanceCounter to something like "whatever base1" breaks the perf counter! It looks like there is a naming convention requiring that AverageBase proformance counter has the CounterName property value on both CounterCreationData and PerformanceCounter to be counter name plus " base", but I never saw this mentioned anywhere - neither by MSDN, nor by Codeproject articles. So, since average perf counters always come in pairs, linked by name, these helpers should make creating average perf counters simpler (uinsg C#/.NET):

        private static void AddAverageCounterDefinition(CounterCreationDataCollection counters,

                        string counterName, string counterDescription, PerformanceCounterType averageType)

        {

            counters.Add(new CounterCreationData(counterName, counterDescription, averageType));

            counters.Add(new CounterCreationData(counterName + " base", string.Empty, PerformanceCounterType.AverageBase));

        }

 

        public class AveragePerfCounter

        {

            private PerformanceCounter averageCounter;

            private PerformanceCounter averageCounterBase;

 

            public AveragePerfCounter(string categoryName, string counterName)

            {

                this.averageCounter = new PerformanceCounter(categoryName, counterName, false);

                this.averageCounterBase = new PerformanceCounter(categoryName, counterName + " base", false);

            }

 

            public void IncrementBy(long val)

            {

                this.averageCounter.IncrementBy(val);

                this.averageCounterBase.Increment();

            }

        }

 

After this, when creating performance counter definition, you could use following code instead of the one shown by the very first snippet:
      AddAverageCounterDefinition(counters, "whatever", "whatever desc", PerformanceCounterType.AverageCount64);
It will add " base" to the name of the sidekick automatically.

And to create corresponding performance counter, you now can do this:
      AveragePerfCounter avgCount = new AveragePerfCounter("MyCategory", "whatever");
     
avgCount.IncrementBy(new Random().Next(100));

 

Comments [0] | | # 
 Tuesday, February 26, 2008
Tuesday, February 26, 2008 2:33:32 PM (Eastern Standard Time, UTC-05:00) (  |  |  |  )

When ASP.NET 2.0 and Visual Studio 2005 came out I hoped that ASP.NET themes will be developed en masse by third parties and sold like those on TemplateMonster.com. Today, tired of ugly GridViews in my apps, I decided to find an ASP.NET theme for at least a GridView, but to my surprise, the only thing I found was this, which is not even a skin. There are millions of sites, books and blogs telling how to make themes in ASP.NET 2.0, but it looks like market for third-party templates has never materialized. Given how fierce the competition in the graphics & UI design world is, I wonder why everyone is missing a chance to take this niche. Microsoft has a few starter themes, but just a few and without live test-drive sites - one has to download and install Visual Studio plug-ins and build the site to see it in action. All this is very strange: it's hard to believe there is no business model in making skinnable themes for ASP.NET applications.

Comments [0] | | # 
 Tuesday, June 19, 2007
Tuesday, June 19, 2007 9:42:13 AM (Eastern Standard Time, UTC-05:00) (  |  |  |  )

Microsoft is showing off its new Acropolis framework for .NET. It seems to be a little more than good old CCmdTarget of late MFC. 

Back in 2001 when I was making a transition from C++/MFC to C#/.NET two things I missed the most were C++ templates and CCmdTarget/Doc/View architecture of MFC-based Windows UI. I could not believe Microsoft didn't port CCmdTarget at the time and naturally wrote my own. But pretty soon it was obvious that with C# and Visual Studio .NET writing ASP.NET web applications was easier than making Windows UI apps, and people wanted web UI more than windows UI.

Combine dwindling demand for Windows UI with inferior development tools and you end up in the situation where software architects don't even debate whether their next enterprise application should have Windows UI or web UI. It's assumed and understood that it will be a web-based application. If you think an application needs to have Windows UI - you will face an uphill battle convincing other project stakeholders it's the right way to go.

Simply put, Windows UI is so out, and web UI is so in that incremental improvements in Windows UI world like WPF and Acropolis is too little and way too late to save the day. We've got AJAX, thank you very much. In my arrogant opinion enterprise apps will not go back into Windows UI world. The last bastion of Windows UI applications is SOHO market, but that is about to change with HttpVPN making it possible to make easily redistributable web applications for consumers and small businesses. Once that happens, Windows UI will become just gaming and other graphics-heavy applications platform.

Comments [0] | | # 
 Tuesday, February 27, 2007
Tuesday, February 27, 2007 11:37:38 PM (Eastern Standard Time, UTC-05:00) (  |  |  |  )

In attempt to create a less dry than your usual "Hello World" ASP.NET application to showcase UltiDev Cassini Web Server, I decided to write a simple web-based MP3 player application using Maсromedia (now Adobe) Flash. I was very surprised by how long and frustrating was my search for a free .NET-based API allowing programmatic access to ID3 tags in MP3 files from C# and VB.NET. I started working with something I found on Codeproject.com, but that piece turned out to be buggy beyond any degree of practicality. My second sweep across Internet yielded a much better (if only somewhat over-engineered) solution - the UltraID3Lib. Its UltraID3 class is the starting point of the journey. The library worked out for me very well. Thumbs up.

Comments [0] | | # 
 Thursday, February 08, 2007
Thursday, February 08, 2007 11:42:07 PM (Eastern Standard Time, UTC-05:00) (  |  |  |  )

All! If you use Visual Studio 2003 or 2005 to create MSI-based setup packages, here's a good one for you: if your installation uses Uninstall and Install/Commit custom actions implemented as an installer class - you are in trouble. In the process of upgrading your product MSIEXEC.exe first loads an assembly with Uninstall custom action implementation - to complete previous version uninstallation. After that it tries to load installer class of the new version to do Install and/or Commit custom actions of the new version. At this point things can get really bad. If your custom action assembly is not signed/strongly named (and in my experience sometimes even if it is signed) MSIEXEC.EXE will fail to load custom action assembly from the new version and will run Install/Commit custom steps from the old one. This means that if you added new code to your Install/Commit steps it simply won't be executed during upgrade. Even worse: Install/Commit custom actions of the old version will run instead of the new one!

This happens due to completely bizarre, to put it mildly, logic of .NET Assembly.LoadFrom() method. .NET Framework has a rule that after assembly is loaded it can't be unloaded unless it was loaded into a separate AppDomain: appdomains can be unloaded and assemblies can't. Two assemblies may end up looking the same to LoadFrom() if they have the same name even if they are located in different folders or have different versions. So what happens here is this: after MSIEXEC.exe loaded assembly named 'X' to do Uninstall custom step, the subsequent attempt to load assembly named also 'X' from another folder to do Install/Commit step does not happen. But get this: one would expect that if you asked LoadFrom() to load assembly 'X' from folder 'Y' it should either load it or tell you it can't. Instead due to some truly twisted logic, LoadFrom() won't fail if it can't load new 'X' assembly - it will simply return the reference to the one that is already loaded. So much for solving DLL hell problem!

Microsoft knows about the problem since 2004
http://support.microsoft.com/kb/555184/

It didn't, however, fix it yet:
http://support.microsoft.com/kb/906766

They recommend giving unique names to custom action assemblies for each new release. Alternatively they say signing an assembly will make problem go away. I tried signing and in my small test project it made problem go away, but not in the "real" one. I am stuck with having to rename custom action installer assemblies for each release. All Microsoft needed to do is this: force installer to create new appdomain and load old version's Uninstall custom steps assembly there and let it run. After it's done, unload the appdomain and create the new one where you load new version's custom action assembly with Install step implementation. That would make it unnecessary to give assemblies unique names - strong or physical. My understanding is that Visual Studio adds a small shim DLL to the MSI package that loads .NET installer classes from the custom action assemblies. This means they don't even need to wait for another MSI API release to fix it - every new Visual Studio or a even a Service Pack for Visual Studio could have fixed the issue that is still with us more than three years later.

Comments [2] | | #