Skip to content

Serving legacy ASP.NET Websites #561

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
0xF1o opened this issue May 5, 2015 · 3 comments
Closed

Serving legacy ASP.NET Websites #561

0xF1o opened this issue May 5, 2015 · 3 comments

Comments

@0xF1o
Copy link

0xF1o commented May 5, 2015

Is it possible to run websites that currently work on IIS 7.5 or mono/xsp4 on dnx/kestrel.
From what i understand it could be as easy as having the right {"commands":{ ? }} in Project.json.

I want to keep my existing workflow (using Visual Studio 2013 Community) for now but want to test the websites with different servers/databases (docker makes that easy...).

Can someone please put me on the right track?

Thanks!

@Eilon
Copy link
Contributor

Eilon commented May 5, 2015

There is no support for ASP.NET 4.x projects (e.g. MVC 5.x and earlier, Web API 2.x and earlier, Web Forms) on DNX. Is that what you're asking for?

@0xF1o
Copy link
Author

0xF1o commented May 5, 2015

Yes... i'm trying to get away without migrating to VS2015... looks like this wont happen

A bit confusing... ASP.NET 5 not supporting ASP.NET MVC 5 :)

Thanks!

@Eilon
Copy link
Contributor

Eilon commented May 6, 2015

Yeah the version numbers are a bit confusing, sorry about that!

Fortunately there's lots of choice these days for editors: VS2015 (Windows only, fully featured), or Visual Studio Code (Windows, Mac, Linux), or OmniSharp (lots of platforms, lots of editors) all serve as terrific experiences for working on ASP.NET 5 applications.

@Eilon Eilon closed this as completed May 6, 2015
natemcmaster pushed a commit that referenced this issue Nov 20, 2018
…tures` package and namespace

- #590, also related to #561
- move feature interfaces from `Microsoft.AspNetCore.Http` package
- move required classes from `Microsoft.AspNetCore.Http.Abstractions` package
- move `ISession` and `WebSocketAcceptContext` to `Microsoft.AspNetCore.Http` namespace (#590)

nit: remove transient dependencies listed in `Microsoft.AspNetCore.Http.Abstractions`'s `project.json`
natemcmaster pushed a commit that referenced this issue Nov 20, 2018
… cookies

- #561
- new `SetCookieHeaderValue.AppendToStringBuilder()` method; avoids per-call `StringBuilder` allocation
- `ResponseCookies` uses `ObjectPool<StringBuilder>` that `ResponseCookiesFeature` provides
 - `ResponseCookies` works fine if no `ObjectPoolProvider` is available
- `IHttpContextFactory` instance is a singleton instantiated from CI
 - make `HttpContextFactory` `ObjectPoolProvider` and `ResponseCookiesFeature`-aware
 - apply same pattern to sample `PooledHttpContextFactory`
- pool is not currently configurable; defaults are fine for response cookies
 - if we need (policy) configuration, would add an `IOptions<HttpContextFactorySettings>`

nit: Add some doc comments
@ghost ghost locked as resolved and limited conversation to collaborators Dec 4, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants