raminasi posted:

The Ctrl-T search is way better than in vanilla.

Nurbs posted:

Someone mentioned NancyFx to me today, and I've read all their documentation and I'm just not seeing the value proposition vs. asp.net webapi. Yes Nancy looks a little less verbose, but I haven't run into enough problems where I see it's...flexibility or 'streamlined' framework as a substantial benefit

Am I missing some obvious use cases?

raminasi posted:

The Ctrl-T search is way better than in vanilla.

a hot gujju bhabhi posted:

I use it primarily for its code style features, since I work a lot of inherited code and I like to try to bring it into line with good style while I work on it, having the highlighting from ReSharper is super handy for that.

Unrelated:

I'm used to ASP.NET MVCs handing of bundling and minification, where you could use a HtmlHelper to include the JavaScript and the internals would decide whether or not to render on script tag serving the minified concatenated JS, or render several tags serving each individual unminified file separately based on your environment. This was pretty useful because you essentially just threw your JS file paths into an array and let MVC handle the rest. It was all in the one place.

In ASP.NET Core MVC, they seem to have removed this in favour of using "environment" tags to render different script tags depending on the environment. The bundler ALWAYS bundles, and it's up to you to include either the bundled file or the individual files depending on the environment. This means every new file needs to be added to the bundle config, AND to the layout view. Is there a way to get the same behaviour as before?

Nurbs posted:

Someone mentioned NancyFx to me today, and I've read all their documentation and I'm just not seeing the value proposition vs. asp.net webapi. Yes Nancy looks a little less verbose, but I haven't run into enough problems where I see it's...flexibility or 'streamlined' framework as a substantial benefit

Am I missing some obvious use cases?

NiceAaron posted:

I haven't done much with ASP.NET Core MVC yet, and I'm especially unfamiliar with the changes to bundling / minification, but I imagine it wouldn't be too hard to write a custom tag helper that reads the bundle config and does what you want. e.g. pass the output file name into the custom tag helper, and depending on the environment the custom tag helper decides to either render a single script tag for that output file, or parse the bundleconfig.json file to find the corresponding input files and render script tags for them.

Shy posted:

I'm pretty sure it appeared long time ago and asp.net propositions weren't there yet.

The Dark Wind posted:

Anyone know of any extensions like these (basically Ctrl + D in VS Code) for Visual Studio 2012? https://marketplace.visualstudio.com/items?itemName=thomaswelen.SelectNextOccurrence

Little things like this are why I end up doing larger coding in VS code rather than Visual Studio...

Sindai posted:

If your ElapsedTicks are smaller than Stopwatch.Frequency (in other words, if the test took less than a second) integer division will give you a 0 there. Just casting ElapsedTicks to a double should fix it. Or multiply by a billion before dividing.

Also, now that I check I think you're actually multiplying by 100 million.

underage at the vape shop posted:

Normally I write it like 1 000 000 000 then delete the spaces, but today I was feeling cocky.

LongSack posted:

Time for my annual “anyone know of a good print library” question. I’m talking about report oriented stuff, which is mostly FixedDocuments rather than FlowDocuments. Where I’ve done them, holy crap is it a pain in the rear end, throwing together grids, stackpanels, textboxes, etc. and having to track the y-values (“heights”) of the various controls for pagination.

Generally, if I can get away with it, I instead offer an option to export the data to excel (thanks EPPlus!) in the name of “flexibility” - here’s the data, do with it what you will.

I’d kill for a decent print library though.

epalm posted:

I feel your pain. I couldn't take the FixedDocument/FlowDocument madness anymore and wrote a text-based, fixed-width printing utility where you specify your column headers, widths, and alignment, and just write rows/cells in a loop. It re-prints headers on page-breaks too. It's not as "cool" as text that flows and wraps and all that, but it works well. Luckily my customers don't care if it's not flashy, they just want something that works and is simple. I've been meaning to open-source it (GitHub, Nuget, etc), but I keep reading horror stories from OSS maintainers.

New Yorp New Yorp posted:

C# 7 has digit separators.

http://www.davidhayden.me/blog/csharp-7-underscore-as-digit-separator-in-numeric-literals

mystes posted:

The easiest way to actually generate printable files nowadays is probably to use some sort of html to pdf conversion program or library, but this won't easily integrate into a desktop application as easily as it would with a web page.

quote:

Request starting HTTP/1.1 POST http://localhost:8085/api/v1/logout 0
[15:52:47 DBG] Request successfully matched the route with name 'null' and template 'api/v1/logout'.
[15:52:47 ERR] Request matched multiple actions resulting in ambiguity. Matching actions:
MyButt.CurrentlyLoadedController.Logout (MyButt)
MyButt.VeryMuchNotLoadedController.Logout (MyButt)

roadhead posted:

Just looking for some hints on places to look...

NihilCredo posted:

Ugh. Either I'm going down a XY problem path, or I'm clashing with Microsoft's 'my way or the highway' approach. Possibly both.

So I have an ASP.NET Core WebAPI application. It can be launched in two different configurations (sort of a master/slave setup), and based on this launch option I want it to change some behaviour (eg. use different auth options, expose some folders rather than others), and the part that's giving me trouble: I want it to expose either one set of controllers or another. Some controllers are active in both, and the configurations / controller sets might change as the application grows, so I would rather not split the application into multiple assemblies if at all possible.

I thought I'd managed to get it working by adding a custom IStartup class, which configured the IApplicationBuilder and IServiceCollection in the appropriate way, then adding .AddControllersAsServices() and explicitly listing which controllers I wanted to be available. (This also came with the bonus of letting me explicitly call their constructors instead of having to trust the DI system.)

Well, it's mostly working, in the sense that if I try to call an endpoint on a controller that isn't listed I correctly get a 404. However, the absolute fuckers in the MVC internals appear to be still doing some reflection-based loading, because if I define the same endpoint route in two different controllers, it does not care in the slightest that only one of the controllers is currently registered in the application - it goes 'durr, this path exists somewhere else in the assembly' and throws a 500:


Looking further into it, it seemed as if I could override this behaviour by also specifying a custom IApplicationFeatureProvider<ControllerFeature> (did I mention I loving love OO engineering?), but it didn't actually work. The next step looks like it might lie in the even more friendly-named IActionDescriptorCollectionProvider, but I guess this is where I should call it quits and just find a different solution, or put up with the limitation by adding more routes.

Anyway, even if this post gets immediately followed by a brutal takedown showing how my idea was fundamentally wrong in the first place, I still want to say this: death to reflection.

roadhead posted:

NihilCredo posted:

Start here:

https://fsprojects.github.io/Paket/getting-started.html

In my experience, whenever you're doing anything non-trivial with nuget dependencies (such as mixing runtimes), first install paket, then try to solve your problem. At the very least, you'll have plain text files to maintain and plain text outputs to read, instead of cryptic XML diffs and VS squiggles.

Essential posted:

I was mistaken in that I thought anything that implements IDisposable should always be in a using block.

NihilCredo posted:

Ugh. Either I'm going down a XY problem path, or I'm clashing with Microsoft's 'my way or the highway' approach. Possibly both.

So I have an ASP.NET Core WebAPI application. It can be launched in two different configurations (sort of a master/slave setup), and based on this launch option I want it to change some behaviour (eg. use different auth options, expose some folders rather than others), and the part that's giving me trouble: I want it to expose either one set of controllers or another. Some controllers are active in both, and the configurations / controller sets might change as the application grows, so I would rather not split the application into multiple assemblies if at all possible.

I thought I'd managed to get it working by adding a custom IStartup class, which configured the IApplicationBuilder and IServiceCollection in the appropriate way, then adding .AddControllersAsServices() and explicitly listing which controllers I wanted to be available. (This also came with the bonus of letting me explicitly call their constructors instead of having to trust the DI system.)

Well, it's mostly working, in the sense that if I try to call an endpoint on a controller that isn't listed I correctly get a 404. However, the absolute fuckers in the MVC internals appear to be still doing some reflection-based loading, because if I define the same endpoint route in two different controllers, it does not care in the slightest that only one of the controllers is currently registered in the application - it goes 'durr, this path exists somewhere else in the assembly' and throws a 500:


Looking further into it, it seemed as if I could override this behaviour by also specifying a custom IApplicationFeatureProvider<ControllerFeature> (did I mention I loving love OO engineering?), but it didn't actually work. The next step looks like it might lie in the even more friendly-named IActionDescriptorCollectionProvider, but I guess this is where I should call it quits and just find a different solution, or put up with the limitation by adding more routes.

Anyway, even if this post gets immediately followed by a brutal takedown showing how my idea was fundamentally wrong in the first place, I still want to say this: death to reflection.

Essential posted:

I was mistaken in that I thought anything that implements IDisposable should always be in a using block.

SimonChris posted:

Why does it implement IDisposable in the first place, if you are not supposed to dispose it?

Essential posted:

Many of you may already know this, but I wanted to share just in case. Here's the link I found originally on the issue: https://aspnetmonsters.com/2016/08/2016-08-27-httpclientwrong/ .

Essential posted:

I learned something today that I wanted to share, just in case it helps anyone else. HttpClient should NOT be used in a using block, even though it implements IDisposable. This can cause some serious performance problems. For us, specifically we had an Azure Function that was scaling up in ways we couldn't understand. It turns out it was due to wrapping an httpclient in a using block. What can happen is it leaves ports open and can even utilize all ports and hang the system up while waiting to free up resources.

Many of you may already know this, but I wanted to share just in case. Here's the link I found originally on the issue: https://aspnetmonsters.com/2016/08/2016-08-27-httpclientwrong/ . Here is a link from Microsoft describing it: https://docs.microsoft.com/en-us/azure/architecture/antipatterns/improper-instantiation/

I was mistaken in that I thought anything that implements IDisposable should always be in a using block.