Sab669 posted:

Dumb Question: What exactly does Microsoft's Reference Source site show me?

I wanted to do some research for a question on stack overflow pertaining to an issue with the ZipArchive object, which exists in System.IO.Compression as stated here: https://msdn.microsoft.com/en-us/library/system.io.compression.ziparchive(v=vs.110).aspx


If I pull up the online source reference: https://referencesource.microsoft.com/#q=ZipArchive

And search for "ZipArchive" I get one Class result with a different namespace and different members. Like MSDN lists a constructor which takes a Stream object but the Source site does not define any constructors, for example.

Clearly I must be misunderstanding something, but I don't know what. I very rarely use the online source reference so I'm not very familiar with it.

Where (if at all) can I find the source code for the object as defined on MSDN?

SirViver posted:

This may be a stupid question, but did you make sure to have the "Hide the script while running" hook script option turned off? That's usually there to prevent the command window from popping up when executing a batch file or console application, but could also affect your WinForm. Showing the MessageBox might simply interfere with TortoiseSVN's attempt to hide the main process window, or reset some flag that caused it to be hidden before.

redleader posted:

some wonderful legacy behavior I don't the time, inclination, knowledge, or energy to investigate further.

redleader posted:

but can't prove it - and I don't the time, inclination, knowledge, or energy to investigate further.

Duct Tape posted:

When returning a value that doesn't require a long running operation (e.g. something local or in a cache or whatever), should I return the value directly

EssOEss posted:

Yes because why overcomplicate matters by adding some pointless level of indirection that may or may not get compiled away as the compiler goes "wtf bro".

Duct Tape posted:

code:

        return await Task.FromResult(10);

Essential posted:

I need to upgrade a dll from 4.0 framework to 4.6, however I have to keep backwards compatibility for 4.0. From what I'm reading this should work if I only use 4.0 stuff on the 4.0 machines. Can anyone confirm this? I don't need 4.6 installed on those machines to continue to use 4.0 features correct? The dll will load without the new framework installed?

So the dll moving forward will target 4.6. And I will put that dll on machines which only have 4.0 installed. Someone please tell me this will work!

NihilCredo posted:

I guess it might work, because the frameworks from 4.0 onwards were in-place upgrades, but this is a terrible idea and you are very likely to regret it.

You have a number of much safer options available, and if you give more details we could suggest the right one. Probably the easiest solution involving the least amount of work would be to split off the 4.6-exclusive features into their own library (which references the 4.0 library), and only install that additional library on the machines that can support it.

Essential posted:

I need to upgrade a dll from 4.0 framework to 4.6, however I have to keep backwards compatibility for 4.0. From what I'm reading this should work if I only use 4.0 stuff on the 4.0 machines. Can anyone confirm this? I don't need 4.6 installed on those machines to continue to use 4.0 features correct? The dll will load without the new framework installed?

So the dll moving forward will target 4.6. And I will put that dll on machines which only have 4.0 installed. Someone please tell me this will work!

GoodCleanFun posted:

If you move that library to 4.6 any machine without 4.6 will error on running the app even if you don't use features beyond the version installed.

I haven't done any serious async stuff yet so not sure if this would work, but could you build new async lib in 4.6 that includes/wraps the existing lib and then extends it? It seems this is what NihilCredo is suggesting as well.

Duct Tape posted:

Yeah, this is my stance as well. I was just worried that I was unintentionally breaking the state machine for more-complex methods by not wrapping trivial results in Task.FromResult. Doesn't sound like that's the case, though.

Duct Tape posted:

Have an async question. When returning a value that doesn't require a long running operation (e.g. something local or in a cache or whatever), should I return the value directly or wrap it in an "await Task.FromResult"?

Red Mike posted:

Supposedly it has some effect on where exceptions would be thrown, but I've yet to run into a case where it actually matters myself.

Night Shade posted:

It makes exceptions throw immediately, instead of faulting the returned Task. This normally isn't a huge deal if all you're doing is

code:

try {
  await thing();
} catch (...) {}

but if you're doing something like using .Select() to turn a list of urls into a list of parallel downloads, having exceptions propagate immediately will interrupt iterating the list. This prevents assigning the result of .Select(), which will leave you with orphaned tasks that iirc will crash your app if they fault and then get collected.

Red Mike posted:

Also, in the 'orphaned tasks' situation, you normally just hit the default uncaught exception handler. Wouldn't crash your app, same as throwing in an async void wouldn't.

https://msdn.microsoft.com/en-us/library/system.appdomain.unhandledexception(v=vs.110).aspx posted:

This event provides notification of uncaught exceptions. It allows the application to log information about the exception before the system default handler reports the exception to the user and terminates the application.

Night Shade posted:

Setting the contrivance of .Select(DownloadParallel) aside, if you're kicking off parallel Tasks at some point in the call chain you need to not be awaiting them immediately regardless of how smart the Task-returning method is. This makes the difference in exception propagation significant. e: because i can trust that an async method won't throw until the Task is observed and is therefore safe to pass directly to .Select / Seq.map / whatever. I can't say the same about a non-async method that happens to return Task.

quote:

Red Mike posted:

Huh, I stand corrected. I'm not sure what ASP.NET and the two other server techs we've used do then, because we've got those events for safety/logging, but uncaught exceptions never cause issues (unless they're actual hard faults).

e: And similarly in Unity on the client-side, actually, but that doesn't have async/await anyway.

chippy posted:

I'm getting some loving weird behaviour with Fluent Validation and MVC I hope you guys can help with.

I've got a very simple validator with only 5 rules:

code:

            RuleFor(x => x.ServiceId).Must(x => x.HasValue).WithMessage("Please select a service.");
            RuleFor(x => x.Animals).Must(x => x.Count > 0).WithMessage("Please select at least one animal.");
            RuleFor(x => x.StartTime).NotNull().WithMessage("Start time is required.");
            RuleFor(x => x.FinishTime).NotNull().WithMessage("Finish time is required.");
            RuleFor(x => x.StartDate).NotNull().WithMessage("Start date is required.");

The problem I'm having is that if the validation on any of the DateTime fields fails, then ServiceId and Animals don't get validated - specifically, ServiceId is listed in the ModelState with no errors, and Animal isn't listed at all. So if I just submit the form empty, I get it back with validation errors given only on those fields. However, once I fill in the date and times, the other two rules kick in and take effect.

Also, in the view, the validation messages for the date and times have the "text-danger" class, while the ones generated for ServiceId and Animals don't.

Clearly, those 2 sets of rules are being processed differently somehow, seemingly in 2 different passes. I presumed that the date and time fields were getting validated client side, and so the other rules weren't getting processed if they failed - however, in either case, the POST does actually hit the controller action before being validated and returned, which I believe doesn't happen if client side fails, as it prevents the POST from occuring? Also, I tried disabling client-slide validation completely, and saw the same behaviour.

Probably also worth mentioning that I was originally using NotNull for ServiceId (which did cause client side validation to occur), and NotEmpty for Animals, which gave the same behaviour, before I switched them to using Must().

Does anyone have any insight as to what's going on here?

e: I just changed them all to 'must' rules and got the exact same behaviour. What the actual gently caress.

Red Mike posted:

Also, in the 'orphaned tasks' situation, you normally just hit the default uncaught exception handler. Wouldn't crash your app, same as throwing in an async void wouldn't.

Munkeymon posted:

Maybe it's because it's the end of the day and my brain is fried but I'm not seeing why a WebApi controller I added as a quick and dirty proxy for our weather data provider isn't getting routed:

C# code:

[RoutePrefix("weather")]
public class WeatherController : ApiController {
    [Route("{*url}"), AcceptVerbs("GET")]
    public async Task<HttpResponseMessage> Get(string url) {

I did add config.MapHttpAttributeRoutes(); to the top of Register in WebApiConfig.cs, so it's not that. It should be responding on localhost:1234/weather/ right?

Munkeymon posted:

ASP still won't route something that looks like a number to {*url} though. I hate the way ASP does routing

SirViver posted:

Also quite fun if you want to route something that may have a "." in the URL content.

For example, if your route looks like api/myroute/{part1}/{part2}, with part1+2 being string variables, you get:

• api/myroute/hello.world/foo
  Works as expected.
  
  
• api/myroute/hello.world/foo.bar
  IIS static file handler intercepts the request (with a 404 response), because clearly you wanted a file due to the dot being there.
  Can be circumvented by modifying the web.config and adding another ExtensionlessUrlHandler with different path filter to the system.webServer handlers section.
  
  
• api/myroute/hello.world.../foo.bar
  You're essentially hosed. The request goes through (assuming you have aforementioned web.config modification), but part1 will be "hello.world" with the trailing dots magically trimmed. Better hope these were not significant parts of an identifier or anything.
  

ljw1004 posted:

I don't think that's right...

Up to VS2012 (.NET4), a task that ended in the "failed" state and which was never observed (i.e. no one ever did .ContinueWith on it) would raise the global unhandled exception handler.

But as of VS2012 (.NET4.5), once async/await was introduced, that behavior didn't make sense. So we removed it. We specifically wanted to support patterns like this, which never signs up anything for after JonesAsync.

code:

try {
  var task1 = FredAsync();
  var task2 = JonesAsync(); // kick them both off at the same time
  await task1; // but imagine if this throws!!!
  await task2;
} catch (Exception e) {
  Console.WriteLine("oops"); // at this stage JonesAsync has never been observed
}

That's entirely unrelated to the question of exceptions thrown inside async void....

code:

async void Button1Handler() {
  await Task.Delay(1);
  throw new Exception("oops");
}

An exception here will cause the exception to be rethrown inside the current SynchronizationContext: https://referencesource.microsoft.com/#mscorlib/system/runtime/compilerservices/AsyncMethodBuilder.cs,223b5f320d791728

What does that do? It varies. I remember trying it inside WPF, Winforms and UWP (each have their own slightly different synchronization context). I remember that there were different behaviors between the three -- ignored? pop up an error dialog? terminate the program? -- but I can't remember which. I think they all involve the unhandled exception filter first.

What does it do when there's no synchronization context, i.e. it hits the threadpool? I think that goes down the unhandled exception filter route and then terminates the program, but can't remember.

What does it do in the ASP.NET synchronization context? I don't know.

ljw1004 posted:

Up to VS2012 (.NET4), a task that ended in the "failed" state and which was never observed (i.e. no one ever did .ContinueWith on it) would raise the global unhandled exception handler.

But as of VS2012 (.NET4.5), once async/await was introduced, that behavior didn't make sense. So we removed it. We specifically wanted to support patterns like this, which never signs up anything for after JonesAsync.

Red Mike posted:

Re: the initial bit though, does that mean that unobserved faulted tasks have no ill effects, so the original situation with the Select wouldn't have any issues (other than the exception being thrown where you might not expect)?

Night Shade posted:

e: actually if Select blows up you may well be left with work happening inside Tasks that you no longer have any way of dealing with unless you've got a CancellationTokenSource you can use to abort them.

quote:

Cannot implicitly convert type 'void' to 'System.Collections.Generic.List<ThingType>'

itskage posted:

What's up with C#'s list constructor returning void?

code:

var things = new List<ThingType>().Add(thing);

Is it just a dumb pattern to try and initialize it and add something at the same time without using an initializer? It's not like I can pass something into the constructor.

Is this working pattern better? If so, why?

code:

var things = new List<ThingType>();
things.Add(thing);