Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Aug 22 10:55
    rytmis opened #67
  • Feb 19 13:13
    anth12 opened #66
  • Jan 15 11:08
    JosephWoodward edited #65
  • Jan 15 11:05
    JosephWoodward opened #65
  • Jan 09 16:24

    jeremydmiller on gh-pages

    Documentation Update for 3.0.0 (compare)

  • Jan 09 16:22

    jeremydmiller on gh-pages

    Documentation Update for 3.0.0 (compare)

  • Jan 09 14:38

    jeremydmiller on gh-pages

    Documentation Update for 3.0.0 (compare)

  • Jan 09 14:28

    jeremydmiller on master

    docs for 3.0, little sample fix… (compare)

  • Jan 09 12:27

    jeremydmiller on master

    using the <TargetLatestRuntimeP… (compare)

  • Jan 09 12:25

    jeremydmiller on master

    bumping to 3.0 (compare)

  • Jan 09 12:21

    jeremydmiller on master

    letting the Nuget dependencies … removed all references in testi… this time SM is really gone and 3 more (compare)

  • Jan 08 17:53
    Pondidum commented #57
  • Jan 08 14:15
    jeremydmiller closed #64
  • Jan 08 14:15
    jeremydmiller commented #64
  • Jan 08 14:15

    jeremydmiller on master

    Tests on Before/After methods. … bumping to Alba 2.2. Added help… (compare)

  • Jan 08 14:15
    jeremydmiller closed #62
  • Jan 08 13:24
    jeremydmiller commented #64
  • Jan 08 13:22
    jeremydmiller closed #63
  • Jan 08 13:22
    jeremydmiller commented #63
  • Jan 08 13:22
    jeremydmiller labeled #63
larsest1
@larsest1
Found the solution!
You have to use TryAddTransient in configureServices()
Then it won't register anything, if it has already been registered.
Jeremy D. Miller
@jeremydmiller
Sure, but that doesn’t help you out with the ordering per se
Unless you mean to do that in the STartup
larsest1
@larsest1
But it does not overwrtie my mocks
Yes, doing it in startup
Jeremy D. Miller
@jeremydmiller
Then this sounds like a documentation effort now
Lauri Kotilainen
@rytmis
@jeremydmiller Hi! Do you know if anyone has taken a look at adapting Alba for ASP.NET Core 3.0? There seems to be at least one rather major obstacle, which is that TestServer will now forcibly replace the Response Body stream with an implementation that doesn't allow for seeking -- this happens regardless of whether one uses an earlier phase of the pipeline to stick in e.g. a MemoryStream.
Jeremy D. Miller
@jeremydmiller
Not that I know of yet if you’re volunteering;) It’s hopefully less churn than it was going from 1 to 2 this time.
Lauri Kotilainen
@rytmis
Haha. Ahahaha.
See, the thing is, now that they're moving to a monorepo model, the NuGet packages that had the word "Internal" in them are in fact going to become internal.
Most of that seems to have only minor effects. But the TestServer changes might actually hurt. I'm trying to bother David Fowler about this over at the aspnetcore slack.
Lauri Kotilainen
@rytmis
On that note, what are your thoughts about versioning this time around? Should I assume that netcoreapp3.0 means ASP.NET Core 3.0? It's either that or yet another separate package, I guess.
Jeremy D. Miller
@jeremydmiller
I’d like to try to multi-target this time. Even knowing that means some conditional compilation.
Lauri Kotilainen
@rytmis
I thought as much.
Jeremy D. Miller
@jeremydmiller
How close is 3.0 to hitting?
Lauri Kotilainen
@rytmis
It's RC with a Go-live license with a commitment to avoid API breakage from now on.
Jeremy D. Miller
@jeremydmiller
Gotcha. I’d been ignoring it for about this reason
Lauri Kotilainen
@rytmis

The new TestServer usage pattern is to use a sort of builder to construct it and then it provides you with a HttpClient that will dispatch the request, so you get the ResponseMessage with its assorted things. Most of the APIs Alba uses are still available -- I've got some initial work with conditional compilation locally. It's the response body that's giving me headache right now.

I should probably look more closely into the TestServer APIs at some point to see if there are other ways of going about this.

Well, I shouldn't say new because for all I know, it could have been that to begin with.
Jeremy D. Miller
@jeremydmiller
You can always cheat and wrap middleware around the normal stack that substitutes out the response body w/ a MemoryStream
Lauri Kotilainen
@rytmis
Nope. I tried that.
Jeremy D. Miller
@jeremydmiller
Why wouldn’t that work?
Lauri Kotilainen
@rytmis
Just a sec, I'll look it up.
Here, I'm in TestServer.SendAsync, and the httpContext has the MemoryStream as a Body that I've set up:
image.png
Jeremy D. Miller
@jeremydmiller
So their theory of how everything is going to work now is to use HttpClient for everything?
Lauri Kotilainen
@rytmis
This is further down the stack when TestServer begins to return the response:
image.png
The ResponseBodyReaderStream is what we see when looking at the response.
Jeremy D. Miller
@jeremydmiller
Okay. Might not be a killer, but the ResponseBody stuff may need to be smarter. Maybe we buffer that on the way back out
Lauri Kotilainen
@rytmis
Yeah. The problem I'm currently looking at is, because of this TestServer behavior, I haven't yet found any way to read the response body from within the HttpContext.
There has got to be something I'm missing here, though. There's no way this is intentional: this would mean that production code that assumes it can replace the Body stream won't work under TestServer either. 🤔
Jeremy D. Miller
@jeremydmiller
Gotcha. Could we have Alba run the request, then replace the response body with a stream that copies (lazily) the content from the stream we get from the HttpClient invocation?
Lauri Kotilainen
@rytmis
Don't know yet. I should probably play around with a plain TestServer to get a handle on how it's meant to be used.
Lauri Kotilainen
@rytmis
Welp, it turns out that the correct thing to do is to not replace the response stream (which is what Alba already did). By letting TestServer keep its own response stream, the resulting ResponseBodyReaderStream actually contains the output.
I still don't quite see how this would work out with a middleware that actually needs to modify the output, but maybe I'm missing something.
Lauri Kotilainen
@rytmis
And with that realization, I'm down to 36 failing tests on Core 3.0.
Jeremy D. Miller
@jeremydmiller
What else is it failing on besides the response body?
Lauri Kotilainen
@rytmis
As of two minutes ago, nothing.
Jeremy D. Miller
@jeremydmiller
That sounds a whole lot better;-)
Lauri Kotilainen
@rytmis
Most of the failures were due to me not having done the 3.0 work for the WebApp project. Once I had that down, it was a couple of minor things. The TestServer changes might still cause some issues, but at least now it all compiles and all tests pass, so I can run it with some real world tests.
Jeremy D. Miller
@jeremydmiller
Good deal
Lauri Kotilainen
@rytmis
I've got an app that has a small number of Alba-based tests that I upgraded to 3.0, I should be able to give that a try soon-ish. In the meantime, I've opened a WIP PR on Github.
Jeremy D. Miller
@jeremydmiller
Cool, I’ll try to take a look today
Lauri Kotilainen
@rytmis
Take your time. I'm thinking the response body stuff is something I should try and get a response for from MS though. It would spare some #ifs here and there and overall give me more confidence that things won't mysteriously break for no apparent reason.
Lauri Kotilainen
@rytmis
Yeah, so uh. I tried the TestServer example code from the aspnetcore docs and added a middleware that sticks in a MemoryStream. It no worky. The pipeline writes to the MemoryStream just fine, but the code I screenshotted yesterday returns a different stream from the respnse, and the end result is an empty response even with the MS-provided example code.
Jeremy D. Miller
@jeremydmiller
Does it really matter? Can’t we just have REsponseBody read from the response stream that TestServer sticks in the HttpContext?
Lauri Kotilainen
@rytmis
Right now, we don't care -- but it's definitely a mistake in TestServer.