Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Jan 11 02:57
    NextTurn synchronize #152
  • Jan 09 10:25
    NextTurn synchronize #154
  • Jan 02 18:45
    manne synchronize #157
  • Jan 02 11:45
    manne synchronize #157
  • Jan 02 11:43
    manne edited #157
  • Jan 02 11:42
    manne opened #157
  • Dec 17 2019 15:52
    khalidabuhakmeh opened #156
  • Dec 05 2019 19:10
    onovotny removed as member
  • Dec 05 2019 19:10
    jongalloway removed as member
  • Nov 17 2019 05:53
    NextTurn opened #155
  • Nov 16 2019 15:59
    NextTurn opened #154
  • Nov 15 2019 00:13

    jongalloway on master

    Update new-projects.md (compare)

  • Nov 14 2019 16:22
    NextTurn opened #153
  • Nov 14 2019 16:00
    NextTurn opened #152
  • Nov 09 2019 20:22
    jongalloway added as member
  • Nov 08 2019 23:32

    onovotny on master

    Update RxUI license to reflect … Merge pull request #151 from on… (compare)

  • Nov 08 2019 23:32
    onovotny closed #151
  • Nov 08 2019 22:56
    onovotny edited as member
  • Nov 08 2019 22:54
    onovotny edited as member
  • Nov 08 2019 21:35
    onovotny added as member
TeBeCo
@tebeco
got no idea out of this one, i suggest you to open an issue on blazor repo if it's specific to blazor SDK
also it's surprising that blazor that is a "client" tech has a wwwroot
blazor server side might be a bit tricky then
Artemov Ivan
@ZOXEXIVO
stop, of course - it's my bad
TeBeCo
@tebeco
?
Artemov Ivan
@ZOXEXIVO
i just migrated my angular app and i have wwwroot in gitignore.
Local build works ok, but build on Linux server use git)
TeBeCo
@tebeco
;)
Artemov Ivan
@ZOXEXIVO
Thanks
TeBeCo
@tebeco
glad you found it ^^
Marvin Rühe
@Marv51
Hi everyone!
Quick question: is the Windows.Foundation.Collections namespace still closed source? Where would I report a bug or feature request?
Karel Zikmund
@karelz
@Marv51 yes, closed sourced. Report maybe through some Windows feedback channel? (no idea)
Marvin Rühe
@Marv51
@karelz Thank you!
prog20901
@prog20901
Can someone please help me with your valuable feedback about https://jio.nexedi.com/ ???? Planning to build a full text static search engine for the given files....
muzharab
@muzharab
Hello. Would appreciate any advice on how to improve the throughput performance of a gateway-like service with requests that have a lot of data. Currently simply copying HttpWebRequest stream to context.Request.Body (OWIN).
TeBeCo
@tebeco
Migrate to aspnetcore on dotnet core would be a huge throughput performance gain
Does that count ^^ ?
muzharab
@muzharab
Yes, I believe it does. So there is a big performance difference?
TeBeCo
@tebeco

Kind of a huge one based on the assumption that you don’t have a bottleneck in your code base
By that I mean that if what is slow is, for example, a hot path using explicit lock() it won’t save you

But it will be a rather great improuvment for both throughput and memory allocation (so less GC hit => less “freeze the world”)

But it means you’ll have to rewrite your app to be aspnetcore compliant
And your third part netstandard/netcore compliant
muzharab
@muzharab
ok. Yes, there will be some challenges with porting because of library-dependencies. Thank you very much for the suggestion.
Markus Schaber
@markusschaber

We just upgraded our dev machines from VS 2017 to VS 2019. Now, during debugging, the "Tasks" View does not work anymore, showing the following message:

Viewing Task information for .NET Core 2.2 is not supported while the process is running. You can either re-target a newer version of the runtime, or view task information for minidumps of .NET Core 2.2.

Actually, the project is targeting .NET Core 2.1 (which is LTS version!), and one of the two affected machines has neither 2.2 SDK nor 2.2 runtime installed.

What's happening here, and how to fix it (except downgrading to VS 2017)?

TeBeCo
@tebeco
Out of curiosity
What about 3.0 ? 3.1 preview (next lts)
Are you using vs2019 preview ?
Did you created a feedback hub issue ?
Markus Schaber
@markusschaber
3.0 is installed, it came with VS 2019.
We're on VS 2019 Professional 16.3.9.
I did not yet create a feedback hub issue.
I'll do so now.
无限风灵
@WuLex
what ?
dude
Markus Schaber
@markusschaber
@WuLex I'm not sure what you mean?
Will Fuqua
@waf
Hello, I'm working a WPF project with .NET Core 3.1. I'm using the new Ready-To-Run feature. I've noticed that a "cold start" of my published application takes about 10 seconds to start up. After that, subsequent starts are less than a second. Any idea of how to decrease the cold start time?
The fact that the "warm start" is so fast makes me think it's not my application logic.
Will Fuqua
@waf

I ran "Process Explorer" to see what it's doing during this long pause. It appears to be extracting a bunch of DLLs out of my exe? For example it reads from MyApp.exe and then writes to ~\AppData\Local\Temp\.net\MyApp\38d4\PresentationCore.dll (one of the core WPF library DLLs). It does this for all the DLL dependencies of my app.

I'm guessing this is how the new ReadyToRun feature works. I'll go see if I can find more info about it. My app is 180MB, which is large, but not crazy large for an ahead-of-time compiled WPF app I think.

Will Fuqua
@waf

Here's a good quote from the .NET blog:

We expect that some of you will prefer single exe provided by an ahead-of-time compiler, as opposed to the self-extracting-executable approach that we are providing in .NET Core 3.0. The ahead-of-time compiler approach will be provided as part of the .NET 5 release.

Karel Zikmund
@karelz
That is single-exe application - it creates self-extracting ZIP. Easy to deploy, but you pay on first startup.
Artemov Ivan
@ZOXEXIVO
Hello!
We have some troubles in SDK Docker Images (v3.1)
Cannot find evironment variable: DOTNET_SDK_VERSION. Why you drop it? Maybe some replacement?
TeBeCo
@tebeco
Stupid question because I have no idea
But if you use sdk based image
The tag of the image drives the sdk version
Not the opposite
Markus Schaber
@markusschaber
Is it official policy that netstandard is dead?
Should we just stop caring and write our code for netcoreapp directly (and multitarget .NET 4.X if needed)?
Symptoms are:
  • (classic) .NET does will not support netstandard 2.1
  • Most or all ASP.NET Libraries and Nuget packages (e. G. Microsoft.AspNetCore.Authentication.JwtBearer) depend on netcoreapp instead of netstandard, making it impossible to reference them from netstandard projects
Marvin Rühe
@Marv51
@markusschaber I believe your wrong, netstandard is a set of API definitions, dotnet core is one implementation of these definitions. Classic does not support the newest netstandard as it is (effectively) deprecated. With Razor, Mono and dotnet core there are still more runtimes available that do or will implement the standard
@markusschaber "Xamarin, Mono, and Unity will be updated to implement .NET Standard 2.1." from https://devblogs.microsoft.com/dotnet/announcing-net-standard-2-1/
Peter Amrehn
@jongleur1983
and .NET 5 will support netstandard 2.1 as well, if I recall right
TeBeCo
@tebeco
Also netcoreapp2.1 Is still supported (was an lts)
Sooooo still netstandard2.0
Markus Schaber
@markusschaber

@Marv51 As far as I know, Razor is not a runtime. Mono and .NET Core are converging into .NET 5, and Unity is a parallel fork of Mono, so there will be only a single implementation left at the end, so no need for any "net standard" which unifies the implementations.

Libraries like Microsoft.AspNetCore.Authentication.JwtBearer are intentionally released for netcoreapp only, not supporting Net Standard (see aspnet/AspNetCore#16813 for one example), forcing all depending projects to go to netcoreapp instead of supporting netstandard.

TeBeCo
@tebeco
And you should not target netstandard2.1 unless you are blocked (very very specific api)
The edge case is when you need FrameworkReference like aspnetcore3.x
Because aspentcore3.x is not “standard” anymore (that’s not a lib anymore but a framework) so it’s tied to the runtime itself
Markus Schaber
@markusschaber

And you should not target netstandard2.1 unless you are blocked (very very specific api)

Thus means I should go to netcoreapp 3.1 directly, which supports my theory that netstandard 2.1 is dying.

We're migrating some applications from 2.1 to 3.1, and almost all projects which were netstandard 2.0 need to be switched to netcoreapp3.1 now, as they have some dependencies to AspNetCore libraries (and if it's just some JWT bearer library).
There should be no reason for such a library to depend on netcoreapp if netstandard is worth anything.
We had planned to update to netstandard 2.1 where we can benefit (e. g. serving etags from ZipFileEntry.CRC32 property), but it seems we'll end up referencing netcoreapp almost everywhere.
TeBeCo
@tebeco
No I mean you should always try netstandard2.0 first for classlib
Now if your lib need a NEW API that was introduced by netstandard2.1 then you target netstamdard2.1