Earlier quoted context omitted.
Aren't you allowed to send a git (err tfs) pull request there at least within the company?
I've read several places that even Microsoft is not standardized on a source control management, some use tfs, some svn, some git, etc.
I found a bug in the .NET framework and fixed it by hand-altering the DLL
31–40 of 124 posts
Re: I found a bug in the .NET framework and fixed it by hand-altering the DLL
#32The real news here is that this is considered special. In most other languages, they'd have forked the source, fixed it, recompiled it for their own uses and submitted a pull request or patch. I'm a big .NET fan, but the fact that we have to jump through such hoops to find and fix a bug, and then still have near certainty that we're going to have to reapply the patch for many updates to come, well, that's just a bit…
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.
Re: I found a bug in the .NET framework and fixed it by hand-altering the DLL
#331. Submit bug report. 2. Wait six months. 3. MS tech will post a comment, "this will be fixed in the next release". 4. Wait two more years. 5. Bug report will be closed as "won't fix".
Re: I found a bug in the .NET framework and fixed it by hand-altering the DLL
#34Earlier quoted context omitted.
> and still chose the hard way Chose? Unless you work on the team that made that DLL, it's likely you'd be jumping through hoops even internally.
i'm glad someone who works at the company like you was able to enlighten us as to microsoft's internal practices oh wait
Re: I found a bug in the .NET framework and fixed it by hand-altering the DLL
#35Earlier quoted context omitted.
Out of curiosity, would you have been able to read the actual source if you wanted?
Microsoft already publishes the source code for the .net framework (and I think other projects like asp.net and mvc) at referencesource.microsoft.com
Re: I found a bug in the .NET framework and fixed it by hand-altering the DLL
#36Earlier quoted context omitted.
> and still chose the hard way Chose? Unless you work on the team that made that DLL, it's likely you'd be jumping through hoops even internally.
i'm glad someone who works at the company like you was able to enlighten us as to microsoft's internal practices oh wait
Re: I found a bug in the .NET framework and fixed it by hand-altering the DLL
#37Earlier quoted context omitted.
---Author here--- I should disclose that I actually work for Microsoft, and still chose the hard way. Fuck the police!
> and still chose the hard way Chose? Unless you work on the team that made that DLL, it's likely you'd be jumping through hoops even internally.
You don't actually jump through hoops. All you get to do is submit the bug, which gets logged in the bucket of thousands of other bugs.
Then the PMs will gather for bug triage for the next release, which have to compete with the next shiny project features. Nobody wants to fix bugs that only one developer has. It's just not worth it. This bug has existed for years, and it is likely you could modify your code to generate different byte code.
So the bug likely won't be fixed for a while.
I love .NET. I am just describing the reality of the process of bug fixing. Also, if you fix it, who knows what else will regress. That also imposes a bias towards not fixing these kinds of bugs.
Re: I found a bug in the .NET framework and fixed it by hand-altering the DLL
#38The real news here is that this is considered special. In most other languages, they'd have forked the source, fixed it, recompiled it for their own uses and submitted a pull request or patch. I'm a big .NET fan, but the fact that we have to jump through such hoops to find and fix a bug, and then still have near certainty that we're going to have to reapply the patch for many updates to come, well, that's just a bit…
---Author here--- I should disclose that I actually work for Microsoft, and still chose the hard way. Fuck the police!
Re: I found a bug in the .NET framework and fixed it by hand-altering the DLL
#39The real news here is that this is considered special. In most other languages, they'd have forked the source, fixed it, recompiled it for their own uses and submitted a pull request or patch. I'm a big .NET fan, but the fact that we have to jump through such hoops to find and fix a bug, and then still have near certainty that we're going to have to reapply the patch for many updates to come, well, that's just a bit…
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 librar…
Ah yes, that's why you pay $$$ for software :).
Re: I found a bug in the .NET framework and fixed it by hand-altering the DLL
#40I did this once with GCC. "But GCC's open source!" you say. Well, GCC is next-to-impossible to compile for a target other than the host, especially if the target isn't x86 or ARM; and GCC maintainers insist on precise test cases to vet a bug, even if the issue is immediately obvious from reading the source code and the bug only occurs in certain very complex situations. (/me looks forward to the day Clang/LLVM become…
> 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.
Maybe in 3.x and MIPS it "just worked". My experience is 4.x and Tilera. Myself and another engineer dumped a week into that sinkhole before giving up.
Clang/LLVM on the other hand… ./configure && make && make install. No other wacky dependencies or build steps. And it generates better code in many cases (particularly when dealing with structures).