Why isn't this getting more attention?

http://referencesource.microsoft.com/netframework.aspx

Maybe I'm just out of it...

This one was odd.

I had a VS2005 C++/CLI project, and in a recent iteration, had added some logging code using the standard library's streams package. One of the things I noticed early, by way of the program absolutely failing to get off the ground and writing an SxS exception to the system event log, was that including the standard library in the default Debug configuration resulted in the program acquiring a dependency on the Debug MSVCRT DLLs. I had been using the release DLLs (via compiler switch /MD) since I didn't want the hassle of having to make sure the non-redistributed Debug DLLs were on the build server and test machines, etc. Having weighed whether it was worth it for getting to include std, I decided it was, and made it a requirement to have the 4 required files (the 3 runtime DLLs and one manifest file) in the target dir at the build server and test machines. That solved the SxS error (Dependent Assembly Microsoft.VC80.DebugCRT could not be found... Last Error was "The referenced assembly is not installed on your system").

Then I switched over to VS2008. I figured it would be pretty seamless, since nothing really changed. However, I kept getting numerous LNK2022 error from the linker, like - "error LNK2022: metadata operation failed (8013118D) : Inconsistent layout information in duplicated types (std.domain_error)". There was obviously something wrong with including the standard library. If I commented out "using namespace std;" and all references to it (there were only a few), the program compiled. The linker was having problems with MSVCMRT.lib - the managed portion of the CRT. How could I change it, since VC++ picks it based on its version? The answer was to change the compile switch from /MD to /MDd for the project in the Debug configuration. Now the layout of the std types is the same, and the linker doesn't complain.

Why hadn't I needed to do this when the project was in VS2005? Perhaps the layout of debug and redist types in VS2005 were the same, or there was some special mode that VS2005 entered when it detected this usage pattern, and which is lost in the conversion.

The request to bring the ANSI SQL standard double pipe ("||") operator for string concatenation to SQL Server has gotten some response from MS.

It is mostly positive, seeing as I never harbored hope for it to make it into Katmai SQL Server 2008. "Michael" left it active and noted the large-ish number of votes for the issue. He mentions that SQL Server uses the "+" operator for string concatenation - yes, we know, and we loathe it. Everyone else uses the double pipe, except, as I've noted, MySql, which makes, with SQL Server, and interesting pair.

Vote now, if you haven't, so we can hope for SQL Server 2008 SP1!

When you see enough advertisement, you see patterns emerge. Someone does something which is pretty creative in order to help their message, and thus their product, stand out; soon it's showing up everywhere as others copy it, looking for the same freshness and appeal.

After a while, certain designs or phrases become almost an institution in their own right: "new and improved", "this weekend only", "no payments until January 2008". I don't really hear these phrases anymore, and almost missed even thinking about what they might mean. For example, I heard the "no payments..." one since I was a kid, when I had no clue what a payment was. So, I didn't think about it until more recently, when I finally understood what they were trying to tell me (and trying not to tell me, like you still have to pay the interest on those months you aren't paying, fool). Did the constant repetition make it invisible or did it finally do it's job and get me to listen? I don't know. You decide.

I came across this add in a Fry's sale flyer. I think this marketer fell into the convention trap, and didn't think of what the term meant in the context of the product. I know I got a bad feeling when I saw the word and the device, only because the word almost always means something bad when paired with it. 

This would make an interesting AI problem to get a computer to understand the inappropriateness of this ad.

In the spirit of deferring execution to the last possible minute, which on .Net means using IEnumerable and in C# 2.0 the yield keyword, I've built a graphics rendering engine which returns rendered objects as an IEnumerable stream. The interface to this engine allows access to an IEnumerable of the rendered objects, which in turn delegates to an object-specific renderer, which in turn delegates to a graphics-system specific renderer. All each one does is to return an IEnumerable to the client object, and defers rendering or otherwise doing computation until the enumeration is iterated. Then it processes each object in turn. This is a nice way to stream computation, since the cost of computation is amortized over each object from the beginning, and each additional one is a marginal, predictable cost, rather than having a huge cost for the first object and then a diminishing cost for subsequent ones. Ad-hoc decision making during the streaming, such as a decision to cancel, is therefore cheaper, since you didn't have to pay for almost all of the result up front. If you've done functional programming, you already know this. We programmers who have done imperative programming most of our lives are just now catching on...

It seems that there are some technical challenges to stacking your IEnumerables high, however. VS apparently does a stack trace to figure out which debug watch language to use, and gets it wrong when it has too many to go through and you get some BCL code iterating your enumeration. Here's what I get when I call List.AddRange on the graphic engine's Render operation for some unit test:

Note that the code is C#, but the watch popup thinks it's dealing with C++/CLI.

Update: Paul Beard notes the apparent scam that Classmates.com is pulling here. Read the comments there for an interesting attempt at astroturfing by some Classmates.com commenter (comment #28).

Once upon a time, I went to Classmates.com and signed up to see what it was all about. Of course, I've been getting emails ever since. I'm not too surprised about that. One day, however, I got an email that said someone signed my guestbook. That, on the other hand did raise my eyebrow. It deserved a look since, well, as you can imagine, given my interests in life, I was not the kind of person to attract friends in a small town high school.

I clicked on through. When I arrived, it appeared that Classmates wanted me to upgrade to see who signed it. I toyed with giving up my numbers for a month of charges, but since the minimum charge is $15 (3 months at $5 / month) I decided seeing who this one soul was could wait until the information was cheaper.

Then, soon afterward, I got another notification that another old skooler signed my guestbook. It was long enough since the first notification where I probably took the same steps as above. The next few months are a blur with all of the activity in my life.

Last month I got another. Suspicious, I decided to look at the list of signing events. That's when I spotted a curious pattern. Here is a shot of the list:

Odd how the number of the month of the signing event is (last event's month + 1). Sure the day of the month is random, but how hard is that to model? It looks like a marketing campaign with a requirement to have a monthly teaser if I've ever seen one. I'd predicted in August that the next would come in September. Let's see how long this pattern continues.

Hopefully, this post will help the search engines to set the record straight about the InternalsVisibleTo attribute for creating friend assemblies. A number of notable .Net voices (Oliver, Juval, James World) used this attribute in pre-RTM code, when the public key token was used, but Microsoft changed it in the release.

In one post in particular, a commenter, Neil, was trying to say that PublicKeyToken isn't available for InternalsVisibleTo - only PublicKey is. C# MVP Oliver Sturm counters by explaining that it seems pointless to use the whole public key, since it is so much longer to copy than the public key token. While this is true, he apparently was unaware of the change when he wrote this. It was changed in .Net 2.0 RTM. MSDN, after remaining inaccurate after release for some 9 months, now shows the correct syntax.

Update: David Kean also points this change out, and notes that it was changed in RC1, which if I recall correctly was released right after the PDC and right before the November RTM. David also has a nifty utility which generates the otherwise onerous attribute for you. Nice.

The window switch window (Ctrl-Tab by default) in Visual Studio has been updated to show a snapshot of the window you are about to jump to. A very nice little feature to have added... it removes a crucial few seconds from the information seek time, which is more psychological than actual time saved, but each little boost adds up.

This method sounds cool - like it would enumerate ODBC sources on a machine.

However, it's not overridden from its base class, DbProviderFactory, which is implemented like so:

public virtual DbDataSourceEnumerator CreateDataSourceEnumerator()
{
    return null;
}

UPDATE:

IEnumerable<Foo> GetFooItems()
{
        yield break;
}

...is what I want.

Given a method that returns an IEnumerable, you can use the C# 2.0 "yield" statement to return the next item in the enumeration. What if you want to return an empty enumeration? The only way I've found to do this is the following:

    if (false) 
          yield return null; 

Any other ideas?

There is a missing constant in the .Net framework. You are supposed to know that MouseEventArgs.Delta is expressed in increments of the constant WHEEL_DELTA, which is defined in WinUser.h. Sure, the MSDN docs have this value, but are we really supposed to hard code it when this statement also exists in the docs for the WM_MOUSEWHEEL message:

The delta was set to 120 to allow Microsoft or other vendors to build finer-resolution wheels in the future, including perhaps a freely-rotating wheel with no notches.

I suggested that the value be made available in the .Net framework (without having to write a C++/CLI class to compile in the value).

You can too... vote here: https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=265810

CodePlex listened to the community and provided a client with edit/merge/commit workflow and anonymous check-out/update much beloved of Subversion.

 CodePlex Weblog : Announcing the CodePlex Source Control Client

I've yet to see how much like Subversion it is, but it seems to be a step in the right direction. Especially notable given that TFS is rooted firmly in the check-out/edit/check-in mentality.

ISO 9075 is the official SQL language standard (synonymous with ANSI SQL). It has supported the double pipe for string concatenation since 1999. Almost every other database supports this operator (the tragically broken MySql reinterpretation being the prominent exception - but who cares?), and thus makes generating more universal SQL cleaner and easier... except that SQL Server doesn't support it.

You can change that. Vote on Connect: https://connect.microsoft.com/SQLServer/feedback/ViewFeedback.aspx?FeedbackID=259291

It's "anisotropic filtering", not "anisotrophic filtering".

Anisotropic = not isotropic = not (an) the same (iso) direction or alignment (tropic).

Anisotrophic = not isotrophic = not (an) having the same (iso) nutritional requirements or processes (trophic).

When we're talking about filtering a texture image so that it has less pixels on one side vs. another, that is non-isotropic, meaning that the filtering isn't the same throughout the image. This is useful when the square texture is projected and has more of a trapezoidal shape due to perspective.

Although care and feeding of your textures could be shown to improve quality, as well...

I found this while reflectoring. It appears that certain generic types are preloaded in order to prime the JIT compiler, and reduce type allocation (setting up MethodTables and EEClasses) latency.

A reasonable thing to do, and probably testing of the framework found unsatisfactory results, so hacks were inserted, and clearly labeled. I wonder if a subsequent service pack will eliminate these?

 How did this mixup get past legal? It doesn't matter - we must STOP THE EVIL EMPIRE. Long live teh LINUX!!!!!11one.

Some good info on what will be in the upcoming Jan (or Feb) CTP for Visual Studio 'Orcas'. It's hard to commit to a mapping layer technology when this is coming out - even if it is February.

http://download.microsoft.com/download/5/9/c/59cd0dc5-4691-4c3e-840c-66d865f27692/mapping.xps

My quote got on a book I reveiewed for Addison Wesley: VSTO for Mere Mortals.

I actually meant it too - it's a good book. Great for the Word and Excel macro-heads who want to dive into more power - power that the CLR and .Net languages give.

I used to disdain departmental power users who took up the code shovel and started digging... but now I'm rather encouraged by it. I think these kind of inroads could indicate paths of least resistance as an organization evolves. Not, probably, what corporate IT wants to embrace. I think the CLR, with Code Access Security, type safety, hostable runtime, adaptable client-side / server-side story, peerless toolset, access to legacy code assets has the lead here.

I am implementing an instance of IBindingListView for a UI binding scenario. This is a fairly complex undertaking, given also that the list is relying on some dynamically generated runtime code to avoid reflection yet give the list the flexibility in dealing with multiple types. Ultimately, I need knowledge of the properties of the type being displayed in the list, so I can parse the IBindingListView.Filter property string and behave correctly under a call to IBindingListView.ApplySort. Enter System.ComponentModel.PropertyDescriptor and the related type description API.

Since I will be dealing with potentially incorrectly cased values in the filter, I need to know how to get a property out of the PropertyDescriptorCollection regardless of case. There is an .Item property, mmm, ok... but what about case? The 'Remarks' section comes to the rescue (as jfo also observes at her new digs):

The Item property is case-sensitive when searching for names. That is, the names "Pname" and "pname" are considered to be two different properties.

This is not the first time that the Remarks section has helped me out. Indeed, it is often the only valuable information in my effort to understand the behavior of the type or operation. This is good to consider when decorating my own types with the <remarks></remarks> xml doc tag - what does the user of this API need to know to eliminate having to make explorations with mockup code?

Now, if only the same existed for expected behavior for an IBindingListView's 'Contains', 'Find' and 'IndexOf' methods in the presence of a non-null 'Filter'. I suppose this is where MSDN Community Comments come in.

A nice corpus to try tuning various algorithms against.