10

Visual Studio in the recent releases got some updates where it "accelerates build time" by caching DLLs or something
Good in theory? sure.
In practice? So very often, a "hot reload" now doesn't trigger a DLL swap. VS says that changes have been updated but you see stale code and you've to turn off the program and re-run it

I'm sure there's a way to turn this acceleration off and will do that after this rant, but I don't get how such retarded features get green-lit and make it to production :v

I understand that for biiiig solutions with minutes of build-time, this would be god-sent, but if it's this unreliable in my 8-Project Solution, I wonder how unreliable it'd be in bigger Solutions

at least turn it off by default if you know it's shit ffs.

Comments
  • 1
    Maybe you can do like a make file: rebuild this component if these sources are changed rule. In make it would be:

    pony.dll: pony.c pony.h another.h
    gcc pony.c -o pony.dll

    Bur I never do that, I always regenerate my projects completely. I want to be sure.
  • 3
    VS has always been rife with cache invalidation bugs, the last thing it needed was one more poorly implemented caching layer.
  • 1
    how do I turn this off? It looks like it could improve my situation too.
  • 1
    the app is complete and the project manager is trying to justify his own existence

    if he was smart he would just fade into the shadows and become a forgotten department just raking in the dough, serving as insurance for maintenance patches and such
  • 1
    @jestdotty Visual Studio is very, very far from done. Visual Studio's caching is very far from done. It would be easy to justify a continuation of the project, for example they could invent a "first of its kind" reactive caching solution that integrates deeply with Windows supervision tools to automatically re-run arbitrary dev tools including shitty glue scripts, file copy operations, and third party stacks such as React when the files they read had changed.
Add Comment