Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
Paul M Cohen
@paul1956
I just got a new PC with a high resolution display and the the same binary app displays ToolStripComboBox and ToolStrip both display very unexpectedly. The height of the MenuStrip and ToolStrip is much large and the ComBox is displaying as a list box.
Joseph Musser
@jnm2
There have been some improvements, but I've never found a good strategy for DPI flexibility with winforms.
Jeremy Kuhne wants to tackle the issues it has eventually: https://youtu.be/m-NdyJVBf2Y?t=1388
Paul M Cohen
@paul1956
@jnm2 you mean this is expected? I can’t even understand what it’s doing to try to workaround it for the 3 broken controls.
@jnm2 forgot I was the video. I will fine some bugs.
Andy Green
@Ydiren
Hi guys. I'm having problems with FileSystemWatcher locking directories, so have been looking for alternatives. I've come across the PollingFileSystemWatcher here in the dot net source browser, but can't find any reference to it in the official docs. I see that the class has been around in the corefxlabs repo for quite some time, does anybody know if this is ready for use and if so, where I can find the binaries to reference?
Joe4evr
@Joe4evr
since it's on corefxlab, there's no binary available (if I understand the purpose of the lab repo)
Andy Green
@Ydiren
That's what I had assumed, but the fact that the code is also in the MS source browser website made me think this was readd
*ready for use!
Joe4evr
@Joe4evr
it's easy enough to clone the corefxlab repo and reference the Polling project yourself to try it out
Andy Green
@Ydiren
Ok, at least I'm not missing anything obvious. Thanks for the pointers.
Joe4evr
@Joe4evr
ah, there's a seperate nuget feed you could pull it from (see dotnet/corefxlab#2804 )
Andy Green
@Ydiren
Thanks again, you've been most helpful! :-)
lambrech
@lambrech
Hi all, I have a short question, and I hope this is the right place to ask it:
It is about the C# 8 nullable feature. Is there a way to mark a referenced library or nuget paket as "null-oblivious"?
Because I have the "Nullable"-feature enabled and I really like it a lot. Sadly most of the packages I am using did not implemente nullable awareness yet.
Joe4evr
@Joe4evr
the compiler should be able to see a referenced library is null-oblivious because it will lack the assembly-wide marker attribute
Jose
@pepone
I building a library and packaging it as NuGet package, then when I use it in an application, the exceptions from the library doesn't show up the line numbers, I have try to include the PDBs in the NuGet package but still not luck, is there a way to get the library line numbers when printing exceptions from an application that uses the library NuGet package?
Igor Velikorossov
@RussKie
@pepone do you package a debug or release version of your lib?
Jose
@pepone
@RussKie It is a debug build I build with DebugType=portable Optimize=false DebugSymbols=true
Matthijs ter Woord
@mterwoord
net47 doesn't seem to understand portable format for that
Jose
@pepone
I'm using 5.0.1 on Linux
Matthijs ter Woord
@mterwoord
ah, not sure then..
Joseph Musser
@jnm2
@pepone the PDBs from your library don't get included into the application that uses your library IIRC
If you wanted to force the issue, you could use DebugType=embedded
I don't like embedded PDBs in libraries that I use in redistributable apps
Jose
@pepone
Thanks, @jnm2 I using portable with source indexing and this works great for debugging, but having exceptions stack traces annotated with line numbers would be great to have, this will help to track issues that happen once the application is deployed
Jan-Willem Spuij
@jspuij
@pepone Just stating the obvious but you are creating symbol packages and distribute them as well?
Magnus Grindal Bakken
@magnusbakken

Hello,

I have a System.Text.Json problem. I recently upgraded my API code to .NET 5, and I'm looking into converting the serialization provider from JSON.NET to System.Text.Json. Standard serialization/deserialization works fine, but I'm having trouble converting a particular pattern.

In my API I have a few places where I distinguish between null inputs and undefined in the input JSON. Specifically, null means "remove this value" and undefined means "keep this value as it is".

The way I've implemented this is with the approach described here: https://github.com/alberto-chiesa/SettableJsonProperties. I have a type Optional<T> which distinguishes between null and undefined, an OptionalJsonConverter which converts literal null properties to null and omitted properties to undefined, and a custom contract resolver that relies on the ShouldSerialize-metod, as described here: https://github.com/alberto-chiesa/SettableJsonProperties/blob/master/SettableContractResolver.cs.

STJ doesn't have custom contract resolvers (dotnet/runtime#31257, dotnet/runtime#36785 ), nor any sort of equivalent of the "ShouldSerialize" pattern, as far as I can tell. I can't figure out a decent workaround, so I'm basically stuck here. Has anyone else done anything similar?

Jose
@pepone
Hey guys, what package do I need to use source code generators with .NET 5.0, I added Microsoft.CodeAnalysis.Common" Version="3.8.0" but getting generator.dll: Could not load file or assembly 'System.Runtime, Version=5.0.0.0'
Joe4evr
@Joe4evr
@pepone I believe source generators have to target netstandard2.0 because they're loaded in-proc
Jose
@pepone
@Joe4evr but can I reference the generator in anet5.0 project?
Matthijs ter Woord
@mterwoord
yes
the compiler loads it, not your process.
you can use source generators in .net5 projects, but also .net core 3.1, or .net framework projects. you just need language level 9
Jose
@pepone
not working for me with Visual Studio 2019, I getting the above error when referencing the generator from a .NET 5.0 project
Matthijs ter Woord
@mterwoord
reference is correct?
how is the reference done?
Jose
@pepone
seems that because I first target .NET 5.0 with the generator, the DLL was still loaded, now is loading fine
I cannot navigate to the generated code but that is probably a different issue
akima15
@akima15

Can someone please explain what things you guys take into consideration when deciding whether to use[MethodImpl(MethodImplOptions.AggressiveInlining)]?

It's used very often in methods that are extremely small and I'd expect the JIT to inline them always but I'm guessing that there are cases where this wouldn't happen without this attribute? perhaps if its called many times in a single method?

akima15
@akima15

I have a method whos code size in IL is 34 bytes that is getting inlined but another simliar one that isnt getting inlined and its IL code size is 30 bytes. So far my conclusion seems to be the JIT is dumb and I should use this attribute in most cases where I want performance.

I need an expert to shime in and please correct me if I'm wrong.

HaloFour
@HaloFour
JIT takes a lot more into consideration than just code size
Matthijs ter Woord
@mterwoord
i'd definitely say jit is very smart, but it can be wrong on occasion
Jan-Willem Spuij
@jspuij
@akima15 https://docs.microsoft.com/en-us/previous-versions/dotnet/articles/ms973858(v=msdn.10)?redirectedfrom=MSDN#method-inlining
Note that it isn't exhaustive and for the classic framework
akima15
@akima15

JIT takes a lot more into consideration than just code size

@HaloFour Clearly, that's why I asked when AggressiveInlining should be used.

i'd definitely say jit is very smart

@mterwoord
Doesnt seem very smart:
https://sharplab.io/#v2:EYLgxg9gTgpgtADwGwBYA0AXEBDAzgWwB8ABAJgEYBYAKGIAYACY8gOgCUBXAOwwEt8YLAJI8YUCAAcAymIBuvMDFwBuGvSatOPfoIDCEfBN4AbMTKjzFKtYykALbFAkAZbMHbc+A1dTUBmJlIGXQYAbxoGSIZeHgBtAF0GRygGAF4GLhgAd2i4+NDyNAZSIr8AXx8opgDgAE8MGAZgMIYAcxgMZQZcDq6yiKjiANw7aAxu8hb2zu7ehn7qKqHu0ahx3CDQtrmemYWByOXiFAY2JQ7yAAoASgOwu6rm9L9KqqjcSfS6V7fuoPS4OQfvMaHdljFxgAVJQYK7Xe6LX6nc6wm7AqoQhgpL7oqIAM2gMGwYDsl1kjgYCFySSgUFuiKRURSAGp0ghcYcAOxY4ELKp3O6xACyHVGABMhIZjJcRRhxZKJMYAPISPgQLi4FgAQVarVguFwvFkMBExhiMVa13iYICx2Ru1INzu4QZbyeDBeD3enwY3y9kQ2aQYgN5Atd4J4DGhuAwjvhLsZZwdaP9uXG2N9HIYBNgxNJ5JSVJiNLpqaqLLZWeI3KgoeoZSAA=

@jspuij Thanks

Matthijs ter Woord
@mterwoord
you want it to inline the Reset1 method? i think there's hardly anything to gain here
only overhead is 1 call and 1 return
akima15
@akima15
@mterwoord Unnecessary overhead and it takes more ASM instructions than would otherwise be required if the call to Reset1() was inlined. Usually not inlining a method and instead calling it gets you less executable binary bloat.
The point is that the JIT doesnt seem very smart here.
In fact the Reset1() method doesnt use anything that is listed in the article given by @jspuij which would 100% prevent the JIT from inlining it.
masonwheeler
@masonwheeler
File an issue then.