I found a bug in the .NET framework and fixed it by hand-altering the DLL

This. One bug in IE9 clickOnce launching thanks to them changing how download prompting works.

1. Reported to connect whilst in preview release status. Closed. Reported again. Closed. FULL test cases provided.

2. We're a gold partner with a £500k spend a year on licenses. Partner support. 19 hours on the phone over 6 months, blame shifting between the IE and .net teams and a daily call to get the case closed without resolution. Got a registry patch from ass-end support after 4 months that we have to ship to 2000 users at 200 different companies rather than an upstream fix. This checks a check box in the security settings.

They broke their own product and won't fix it. Basically you can't use JS to redirect to a clickonce URL.

Now today, IIS just stopped serving shit with no errors, nothing. Can't get anything out of minidumps+windbg. Just stops. None of our code is running.

Who am I going to call?

Redhat that's who.

Hah. I filed a bug via MS Connect years ago and it was eventually fixed in release. It may take time, but it sometimes works.

I've had more luck then. Strange they first say it will be fixed and then later say it won't be fixed anyway, I always had the impression they had their stuff together at Connect. Slowly of course but I guess that's what's to be expected because of the sheer size (this is not in their defense, at all, just my idea of why that is). Probably also spend tons of time looking at issues posted by people thinking Connect is a Q&A like StackOverFlow. Anyway for the 6 or so bugs I filed, all for the C++ compiler, the flow was

1. Submit bug report. 2. Get response like "we're looking into it" 3. Wait 2 to 5 months

4a. MS tech (or sometimes event Stephan T. Lavavej himself) posts a comment, "this will be fixed in the next release" 5. Bug report closed as fixed 6. Wait x time where x mainly depends on the point in time of the release cycle where 1 occurred. The later 1, the smaller x. You've gotta time those bugs to get them fixed quickly :P

4b: "won'tfix" / "by design" i.e. I got an explanation of what I did wrong, or otherwise why it happens

4c: "deferred" i.e. posted something that can be worked around and considered too minor of an issue to fix soon

So, do you think this is Dino's fault? :P

---Author here---

AWESOME TIP, stoked to try it out, thanks!

Just recently I wrote https://github.com/ikonst/LongPathFix to work around a clang/gcc issue, cause it seemed easier than going through the hoops of building clang for Win32, understanding its code and writing a patch good enough to be accepted.

> Well, GCC is next-to-impossible to compile for a target other than the host, especially if the target isn't x86 or ARM;

You're exaggerating. I had no problems compiling gcc 3.something targeting MIPS-I on an x86 Linux host.

Cross-compiling and Canadian-cross isn't fun but isn't that bad. There are good projects out there to help in the process. http://crosstool-ng.org/ is a good project that can make it much easier. They have Canadian-cross support but I haven't used it.

Back in the day, crosstool was a solid way to build cross-compilers:

http://kegel.com/crosstool/

I haven't really kept up with the latest stuff, but I've seen mentions of crosstool-ng, which may be a newer take on it:

https://github.com/diorcety/crosstool-ng

So, no, it's not next-to-impossible. It's a little complicated, and that's why these projects exist, but my memory of crosstool was that it made it trivially easy: run the script, let it compile for a bit, and voila, you now have a brand-new cross-compiler toolchain.

The point of free software is you can do what you want with it, including fixing it if needs be. I believe Stallman started the movement from frustration that he couldn't fix a problem in some software he used.

As the former opposite of the freetard and greybeard, a mere corporate VB peon, you are 100% spot on.

Most of the commercial software dev stuff is like regularly salting and sandpapering your genitals. And I'm not talking about fine grit paper either. Even relatively popular fields like .Net are painful on a daily basis.

I really like to see inside the black boxes when they inevitably go wrong. Hell getting a backtrace out of a dump file on windows from commercial software is an art in itself for example.

I had the fortune of inheriting a Sun SparcStation 20 in 1999 that was being thrown out. That and NetBSD literally drove a spike through my mind and entirely destroyed my conception of proprietary closed source software. I really wouldn't touch it now but the money sorting out all the shitty little problems is pretty good, even if it tries to stab you in the face 5 times a day. There's lots of work as well unlike my preferred field of Unix and C.

So I agree with you but I'm a slut for cash and unreliable black boxes of software is good money even if it does feel like I'm the IT equivalent of a STD ridden stripper.

You are justifying closed-source tools by using a closed-source tool to debug your closed-source tools?

Don't pay for Reflector. Throw JetBrains some more money - DotPeek [1] integrates nicely with ReSharper, or you can use it on its own for free.

I think the latest build can also provide PDBs to Visual Studio on the fly by acting as a source server (insane).

After years of Reflector being a free tool, Redgate added a time-bomb to new downloads and released a statement [2]

[1]: http://www.jetbrains.com/decompiler/

[2]: https://web.archive.org/web/20110205074826/http://www.red-ga...

DLLs are signed. But they aren't checked every time a DLL is loaded. It absolutely obliterates load time if you have to go through every byte of all your DLLs and hash them. (You have the option to turn this on within the registry, though)

Signing is almost useless in .Net. And it's certainly not in place for security purposes.

Signing wouldn't have addressed this because they're creating a new, modified executable. So they just make that one unsigned.

Don't worry, each new version of C# gets more features from F# and Scala, this year we will get more syntax sugar and an extensible compiler (with proper IDE support - unlike F#): https://roslyn.codeplex.com/wikipage?title=Language%20Featur... . They will add pattern matching and maybe something more interesting in the version after that. There aren't too many practical reasons to pick F# over C# today and soon there will be even less. Lesson to learn: don't pick *ML language as a foundation. I am glad that Scala is evading F#'s academic fate.

I do both C# and F#. But, at this point I think in ML no matter what which language I'm using. That said, though I'm delighted by F#, there are things that I really miss about C#:

* Haskell's type classes are awesome, and neither F# nor C# have them. But, you can realize them with a really simple pattern in C# whereas in F# you have to resort to reflection or generic hacks[1] (but inline functions usually make such hacks nicer in F#).

* Sum types are awesome. F# realizes them in two ways: with discriminated unions and pattern matching (mainly), or with abstract classes and inheritance. Both are powerful approaches, but the latter is particularly useful when you need unbounded sum types. Unfortunately, inheritance is somewhat crippled in F# because you can't define protected members (though you can override them). I find myself needing this when I'm designing a solution rather than merely implementing one. For instance, I find that designing a language/compiler is much easier with C# than with idiomatic F#.

* This is kind of a summary of the first two points: idiomatic C# is a better dynamic language, and I'm not referring to the `dynamic` keyword, though it certainly helps. I've created some really nice and secure APIs by making use of user-defined conversions. System.Linq.Xml is a good example of what I'm talking about.

* Finally, idiomatic C# is a nicer classical OO language than idiomatic F#. This is kind of obvious since F# is a "functional language" with OO features whereas C# is an OO language with functional features. But, when I say classical OO, I mean the Smalltalk style OO that came before C++. Alan Kay defined that kind of OOP as (1) Encapsulation, (2) Message Passing, and (3) extreme late binding. Neither C# nor F# quite has (2) and (3), but C# gets me the closest without coloring too far outside of the lines. Of course, this begs the question that OO is better than functional. Having done both for a long time, I'm convinced that it is the case (though I do think learning functional programming is the fastest path to getting good at OO). Lamentably, I can't yet defend this point too vigorously because I've only just discovered the joy or Smalltalk. But, here is a preview of sorts: Imagine being able to update a database schema and having your statically-typed code continue to run without needing to recompile.

[1] http://stackoverflow.com/questions/9868327/f-type-constraint...

How would you enforce that? First, hashing every byte of every loaded DLL destroys your runtime.

Second, if you're able to modify one DLL, you could overwrite whatever DLL was tasked with computing the checksum.

They recompiled with the new binaries.

You can produce and consume signed libraries in .NET very easily. In practice it's becoming less common as .NET becomes more open.

As an aside, OP says he works with Bart De Smet and they're messing with expression trees. I bet that this is work related to Cortana and the expression trees are used for compiling standing Rx (Reactive Extensions) queries which Cortana uses extensively on the phone and in the cloud.

The fact that people think you shouldn't be able to do this is what really scares me. :)

I should be able to change the software on my own machine, stored on and running on hardware I own, in whatever way I desire and have it do what I want. (And in practice I have - opening a binary in a hex editor and changing a few bytes is not at all beyond me.)

You need to be a local administrator to write to the GAC by default. See http://msdn.microsoft.com/en-us/library/yf1d93sz(v=vs.110).a...

So if you can modify the files in the GAC, you're already compromised at that point.

They didn't replace it - it looks like they created a new assembly with its own strong name, registered it alongside the 'official' assembly, and referenced their assembly in place of the .NET native assembly at compile time.

What's maybe surprising is that the C# compiler generated code 'adopts' the types in their hacked expressions library. But the C# compiler, wherever it depends on particular types that need to exist for it to do its thing, has always generally relied on finding those types by -name-, not by -name and assembly strong name-.

For example, the C# 3 compiler understands the calling and declaration syntax of extension methods, but to compile an extension method, it requires an Attribute type - System.Runtime.CompilerServices.ExtensionAttribute - which was only introduced into .NET in v3.5. But if you make an attribute class with that name available to the C# compiler, you can compile code using C#3 extension method syntax against the .NET 2.0 framework libraries.

I don't think it's a replacement, since signing the new DLL would require a new key. (GAC DLL identity basically comes down to name + signing key. So even if you call it System.Whatever, it has a unique identity)

I work at a startup that uses almost all open source tools for our stack. To not be able to fork, fix, pull request a bug in software seems...barbaric to me.

---Author here---

I should disclose that I actually work for Microsoft, and still chose the hard way. Fuck the police!

What they're doing here is monkeypatching the language runtime. That's not trivial in most languages, least of all ones which typically rely on a centralized install of that language runtime to function.

The way they did this, only the program that needs this fix is actually using their monkeypatched Expressions library; other code on the same system - other libraries in the same application, even - will continue to use the standard .NET runtime classes. That's a pretty powerful capability, and not one that is necessarily made easier by an open language runtime.

Regarding open-sourcing .NET: did Microsoft not precisely do this (at least some of its components)? http://thenextweb.com/microsoft/2014/04/03/microsoft-cloud/

I've very rarely heard of shops running forked, re-compiled runtimes for languages like python or ruby.

Normally if you find a bug in the core you might try to monkeypatch but many times that won't work so you have to suck it up and just work around it.

1) You can file bug reports against .NET and they get fixed. (Typically very slowly, but that's enterprise vendors for you...)

2) The tools they used to find & fix the bug are all based on fully-specified, documented, and supported mechanisms: ildasm and ilasm are stock .NET tools, and ilspy is using Mono's IL decompiler/compiler library.

3) You can compile an app against your own builds of any of the standard libraries if you want (including mscorlib, with caveats) and run it, so a fix like this can be deployed and maintained as much as you like, even if it's not Great Engineering.

4) This hand-patched DLL wouldn't corrupt any other app on your system, and you can ship and version it yourself, so it wouldn't break as a result of a system-wide .NET hotfix or anything like that. .NET's fully-specified ABI also means that it will work across all supported platforms.

5) Mono is open source, so you could always ship against mono and mono's mscorlib (both open source, naturally) if you absolutely can't wait for a .NET bugfix to ship AND you're unwilling to patch the dll yourself.

People love to bitch about .NET, but it actually provides a really good ecosystem here. Very little of it is truly a black box, the spec is extremely readable and precise about the things it covers, IL disassembly is extremely readable, IL disassembly fed through a decompiler like ILspy/dotPeek is doubly readable, debugging is straightforward even without symbols, and recompilation/patching is trivial because everything is well-specified and there's a robust open source library for it. (Even if there wasn't a library, you could just use the standard ildasm/ilasm pair.)

Oh, and you can compile native no-kidding C/C++ to .NET targeting the same instruction set and get all the benefits of the above. If you want to.

It's not that special, and they took one hell of a circuitous route to fix their bug. You can download the source and view the bug here:

http://referencesource.microsoft.com/#System.Core/Microsoft/...

I know what you mean, I like .NET too but there is a lot about working with it that feels very outdated these days.