61–70 of 124 posts
Funny, I had something to do with this code back in the day! I'm guessing it was a copy+paste bug and they copied from the LambdaCompiler, which uses StrongBox for its closed-over parameters[1], since StrongBox .Value is a field. The idea was to have the closures be really fast. The history of ET compiler: it started with LINQ in .NET 3.5. Originally it was pretty simple and just handled expressions. In .NET 4.0 we m…
I wish i knew about it about a year ago for a project I did.
Assuming they haven't been obfuscated, this is an extremely useful tool. I've used it to track down a number of issues within Visual Studio itself and within some of the non-open sourced components of Roslyn.
[1] http://www.red-gate.com/products/dotnet-development/reflecto...
Funny, I had something to do with this code back in the day! I'm guessing it was a copy+paste bug and they copied from the LambdaCompiler, which uses StrongBox for its closed-over parameters[1], since StrongBox .Value is a field. The idea was to have the closures be really fast. The history of ET compiler: it started with LINQ in .NET 3.5. Originally it was pretty simple and just handled expressions. In .NET 4.0 we m…
So, do you think this is Dino's fault? :P
Why wasn't the DLL signed? Is this not a thing?
Signing is almost useless in .Net. And it's certainly not in place for security purposes.
My knowledge of the GAC is out of date but isn't a bit of a security hole that you can replace that DLL?
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.
Earlier quoted context omitted.
From good source here: 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 mo…
> Nobody wants to fix bugs that only one developer has. It's just not worth it. … Also, if you fix it, who knows what else will regress. That also imposes a bias towards not fixing these kinds of bugs. This is an interesting cognitive hazard: it's relatively easy to measure the cost of paying a developer to fix a bug and possible to estimate the cost of getting it wrong but there's no way to measure the cost to every…
The cognitive hazard is a good observation.
But I think the most important one is the imbalance of interest, which is where open source shines: MS gets zero value from fixing this bug and a lot of value from adding new features, but for this one developer this bug could have been the most important issue on the road to his company's "value" (their own product's ship date).
In situations like this, you can report the bug to Microsoft Connect: 1. 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".
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.