Skip to content
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

Add support for ASP.NET (non-Core) projects #2670

Open
NickCraver opened this issue Jul 27, 2017 · 66 comments

Comments

@NickCraver
Copy link
Member

@NickCraver NickCraver commented Jul 27, 2017

We routinely run into cases where the new project system and ASP.NET MVC 5 collide (or rather, don't) - I'd like to see support added. Here are the main use cases I'm aware of, I hope others add more to this issue:

Use Case: Migration

One of the awesome features of the new .csproj system is glob patterns (and Visual Studio not replacing them on every save). This was something we really looked forward to as a real time saver and merge reducer, but in practice we can't use the new project system because a lot of functionality for ASP.NET MVC 5 apps is missing, e.g. even hitting F5 to run it.

When we migrate a large solution to ASP.NET Core, it's a stop-the-world endeavor as are most major changes. Swapping any fundamental framework piece will need to be a big swap, so you want to reduce that window and risk as much as possible. In the case of ASP.NET to ASP.NET Core, you need to swap the project file, all references, port controllers, views, etc. This is a lot to do at once, and every change since you started that path is a royal pain.

A large part of this pain is in the project file itself, since nearly every commit adding or removing files is a merge conflict. And when moving from non-glob to blog worlds, it's a huge pain to manually sync everything into that major change branch.

But why not just stay on non-globs until after the move?

Again, merge pain. A large change like this necessitates moving files around quite a bit and that's the same merge pain between users as exists in 1 world today.

Use Case: Library Projects

We also have several projects that need to support ASP.NET and ASP.NET Core, there are hundreds of thousands of users on the old systems and we need to support them. In the ASP.NET cases specically, we need to have a ASP.NET and an ASP.NET Core sample. In all of these, the only use of the old project system is the ASP.NET (non-core) sample projects. We have to choose between:

  • Leave it as the old project system, managing both in different ways forever.
  • Screw it, upgrade and host it in IIS, manually attach debuggers, etc.

Adding support for ASP.NET MVC 5 projects for example would help tremendously in porting to ASP.NET Core. In our case, it'd help now for library projects (needed dependencies for main websites to move), and later for those sites like Stack Overflow. We've been working on the .NET Core story for quite a while now, but the daunting task of upgrading the main applications would be made much easier if we could get on the new project system first.

For today examples, I'm using the new .csproj in MiniProfiler and Exceptional MVC 5 Sample projects. The upside is management and simplicity, the downside is users constantly asking why F5 doesn't work. At the moment I'm considering changing them to the old system since the main point of a sample is a bit missed when they can't test it.

Use Case: Immediate

Additionally, it'd just make life easier today in itself, apart from upgrade reasons, by:

  • Eliminating most of the cases we run into merge conflicts today
  • Make git history usable (e.g. when did we upgrade library X?)
  • Reducing project and solution reloads
  • Not restarting Visual Studio constant because of the above (this is still faster than reload in VS 2017)

Can we please consider adding support for these project types? Such support would make life easier both immediately and for upgrading in the future.

@NickCraver

This comment has been minimized.

Copy link
Member Author

@NickCraver NickCraver commented Jul 27, 2017

cc @davkean @davidfowl - we've discussed this a bit before as I beat my head on the wall making these things kind-of-work in testing the new system.

@mduu

This comment has been minimized.

Copy link

@mduu mduu commented Jul 27, 2017

One more:
The project files are the files most often result in merge-conflicts because multiple dev added or even renamed files in the projects. Project files are the bottleneck here as most work will result changes in the csproj. Even if the developers work in totally different areas of an assembly chances are high they will get merge conflicts.

@xt0rted

This comment has been minimized.

Copy link

@xt0rted xt0rted commented Jul 27, 2017

I'd love to move my projects over to the new system but I'm forced to stay with MVC5 until all dependencies work on .net core as they do today.

Since EF code first migrations don't work with the new system the two projects that would benefit from this the most can't be updated (the website & the DAL). Because of this there's nothing to be gained if I migrate the other smaller projects.

If web projects were supported then one of my two sites could be fully updated, and the other could allow for everything but the DAL project making it worth my time.

@mbp

This comment has been minimized.

Copy link

@mbp mbp commented Jul 27, 2017

For the immediate use case, the new project file format provides some great features such as transitive references. And for some reason, updating packages in a large solution with the old project file format takes ages. Just being able to hand-edit the csproj to update version numbers is one of the best features in it.

@JesperTreetop

This comment has been minimized.

Copy link

@JesperTreetop JesperTreetop commented Jul 27, 2017

As someone with a lot of MVC5 projects, I have considered migrating them to the new csproj, since there's a lot to like. Since NuGet package scripts don't work, this breaks or at least makes working with Entity Framework migrations an unsupported scenario. (See xt0rted's comment.) They are present in all or almost all of the projects I had in mind, so that's a roadblock. Additionally, some NuGet packages that insert themselves into the build process would probably need to be similarly adapted, not to mention any project-type specific tooling (Microsoft or otherwise).

The features in the new project system would make my life easier - If this could magically be made to work, or if Microsoft would decide to make it a supported scenario and update EF(6) to work (or allow the community to help out), I would consider moving. As an unsupported it-seems-to-work-but-you-break-it-you-bought-it scenario, I wouldn't.

@scottsauber

This comment has been minimized.

Copy link

@scottsauber scottsauber commented Jul 27, 2017

At DevIntersection in May it was said by a MS high up in a session that the new project system was coming to older projects by the end of the year this year, FWIW.

@shaggygi

This comment has been minimized.

Copy link

@shaggygi shaggygi commented Jul 29, 2017

@scottsauber I seriously don't think this will happen based on this Repo Roadmap for milestone 16.

@dirething

This comment has been minimized.

Copy link

@dirething dirething commented Aug 1, 2017

I have a number of solutions that contain projects that cannot migrate anytime soon as they rely on things like signalR in its current form, MSMQ and EF code first. It would be nice to be able to start new work where possible in the new system until I have the manpower available to rewrite the main components that rely on things the team has decided not to support in a directly upgradeable manner or does not yet support.

The library scenario would at least allow some work to begin moving in the right direction here.

@davkean davkean added this to the Unknown milestone Sep 4, 2017
@NickCraver

This comment has been minimized.

Copy link
Member Author

@NickCraver NickCraver commented Sep 30, 2017

Every time we reload the Stack Overflow project (git pull), Visual Studio 2017 crashes. Every single time. Everyone here experiences this, and every time we fix a bug, another pops up later causing the same. While not related directly to this issue, most of the time the project file didn't need to change. Simple support of globs would have prevented the vast majority of reloads in the first place.

Can we please get an idea of if this will happen? It's the most upvoted issue in this repo and causes tangible daily pain. We want to move to ASP.NET Core, etc. but that's going to take probably a year+. I'm sure there are many, many people in the same boat. Please, add support for the current projects most ASP.NET developers are dealing with and will be for some time.

@davidfowl

This comment has been minimized.

Copy link

@davidfowl davidfowl commented Sep 30, 2017

Honestly I don't see this happening in the short term (this year). There are lots of kinks to work out with SDK projects and the new project system before we can bring them to older projects. Those kinks don't even have anything to do with ASP.NET so then there would be a bunch of work that needs to happen to port ASP.NET things to the new project system which is non trivial e.g. old razor editor, aspx editor, webforms designer??, build system (WAP projects have a hybrid msbuild + build manager build system), and any other quirks that System.Web requires. Some of those components are written in native code since the older project system was native.

All of this to say, it's not a simple flip the switch, it's the same set of people working on new and existing project systems. When the SDK projects are near flawless, I'd look at bringing it to down level projects.

@NickCraver

This comment has been minimized.

Copy link
Member Author

@NickCraver NickCraver commented Oct 1, 2017

@davidfowl I realize to support everything takes more work, but there's a lot of audience covered with far less than all of that. For example out of that entire list only the old razor editor applies to everything we have. But, I'm not sure what's even required there, as the razor editor appears to work as-is. Not listed is F5 debugging, which today results in:

Unable to run your project. The "RunCommand" property is not defined.

I am using the new project system for sample applications in our library projects because I have to. You can't mix old and new (see migration issues in the initial post here). It mostly works, but you can't F5 it because it can't launch. The editors work. The build works. Everything we need for daily almost works, if only F5 would start and attach. How much work are we talking about to make that work?

We don't have webforms, we don't have .aspx, we don't have build issues with WAP, and apps run fine in all our IIS setups (that's how we have to run them on the new project system). That's passable for sample apps (but really, what choice do we have?) but not for a team working together. I guess I disagree on what the minimum bar is here for a huge daily life improvement.

If F5 worked for spin-up debugging (sometimes attaching isn't practical), we'd have moved over already. What would it take to make this work?

@davidfowl

This comment has been minimized.

Copy link

@davidfowl davidfowl commented Oct 1, 2017

It might be acceptable for you but I'm like 85% sure we need to have fully parity before claiming that something is a replacement. Those missing features are probably fine for your development but what about other people? Do we replace the default file new or this is just a hacky edit your csproj and hope it works solution for stackoverflow developers?

If we can't replace the file new project templates for existing ASP.NET 4.x applications then it's not ready yet. You won't believe the sorts of things people rely on Day to day in their projects. Forget those basic features I mentioned, there's also other extensions and features that interact with our project system that would need to work.

That said we could be making incremental progress but it's not a priority. It needs to work well for .net core projects and it really doesn't as yet. There's lots of performance problems that we're actively working on. To expand the scope of the project system before we worked out some of those major kinks would be a disaster

It would be awesome if our web project system was OSS so people could contribute and help make this a reality.

@NickCraver

This comment has been minimized.

Copy link
Member Author

@NickCraver NickCraver commented Oct 1, 2017

@davidfowl We're already in a very hacky state to even think about migrations, anything would be an improvement here. All MS effort appears to be going into a new system we can't realistically migrate to because the old system has been neglected. We have to use VS 2017 for current versions of C#, but to use it with old project systems we're crashing multiple times a day. We can't use VS 2015 unless we want to stick with project.json. We are dedicating our time to libraries on project system in hopes others can use them but we can't even do it ourselves.

We're stuck in a terrible position here. We can't move to the new stuff that works. Efforts to support the new stuff are quite obviously breaking the old stuff and we're suffering for it with zero benefits. I can honestly say: as things stand, we'd have been better off staying on Visual Studio 2015. Yes, I mean that. But it's too late to go back without significant work, we now use a C# version it doesn't support pervasively.

There is no incremental migration story. The solution is all or nothing at the moment due to the new project system not supporting all the projects people already have. dotnet msbuild is the same story, since it can build new things but not old projects.

And let's not forget the clock is ticking. It's already been said that ASP.NET Core 3.0 will drop .NET Framework support and move to .NET Core. This means we have a time limit on an incremental migration story that we can't even begin yet. Due to issues like this migrations to ASP.NET Core remain a logistical nightmare. My teams are asking when we can upgrade and I don't have an answer for them because of these blockers.

@davidfowl

This comment has been minimized.

Copy link

@davidfowl davidfowl commented Oct 1, 2017

All MS effort appears to be going into a new system we can't realistically migrate to because the old system has been neglected

That's very far from the reality of the situation. I'm going to guess you're specifically talking about SDK projects and nothing more. PackageReference was actually ported to the old style csproj without requiring the use of SDK projects.

We have to use VS 2017 for current versions of C#, but to use it with old project systems we're crashing multiple times a day.

That sucks. I can't speak for what changed here that's causing the existing project system to crash multiple times a day. I assume you've given dumps to the appropriate people and they're looking at it?

We can't use VS 2015 unless we want to stick with project.json

This is confusing? Are you using both .NET Core projects and .NET Framework projects in the same solution? Is that the issue you're facing right now?

We're stuck in a terrible position here. We can't move to the new stuff that works. Efforts to support the new stuff are quite obviously breaking the old stuff and we're suffering for it with zero benefits.

Do you mean that you can't move new projects to ASP.NET Core or .NET Standard because it requires the new project system? Can you be more specific here?

There is no incremental migration story. The solution is all or nothing at the moment due to the new project system not supporting all the projects people already have. dotnet msbuild is the same story, since it can build new things but not old projects.

Yes this is true and I don't see this changing for a while. Changing all of the old things to the new project system will take years. Certain project types will be easier than others but it's not easy changing them all with full parity (see roslyn 😄 for a similar story, that took ~5 years).

And let's not forget the clock is ticking. It's already been said that ASP.NET Core 3.0 will drop .NET Framework support and move to .NET Core.

That's absolutely false, that was never said. The thread that got out of control made tons of assumptions that maybe that was one of them. Nobody from Microsoft said that ASP.NET Core 3.0 is absolutely dropping .NET Framework support.

Some questions for my education:

  • What are the big things you are struggling with at the moment?
  • Why is supporting is ASP.NET 4.x with an SDK project a stepping stone to ASP.NET Core support?
  • Why can't you use both ASP.NET Core and ASP.NET in the same solution?
  • Do you have .NET Standard libraries that are shared between old and new?
  • Can you list out some of the pains you have migrating (any pains really)?
@NickCraver

This comment has been minimized.

Copy link
Member Author

@NickCraver NickCraver commented Oct 1, 2017

I'm going to guess you're specifically talking about SDK projects and nothing more. PackageReference was actually ported to the old style csproj without requiring the use of SDK projects.

Correct, talking about this area. <PackageReference> is a great concept, but broken in the older world. It took us a full day to get a build setup and working on and decided against attempting it with any further ASP.NET non-Core projects. We can use it in libs, that's it.

I assume you've given dumps to the appropriate people and they're looking at it?

For all but the latest yes. We've hitting yet another crash in the new preview. We're hopeful when hitting the update button that things will improve from one preview to the next but honestly it's 50/50. From a time standpoint though, we can only invest so much. We need to do our work, not fight with Visual Studio all day.

Do you mean that you can't move new projects to ASP.NET Core or .NET Standard because it requires the new project system? Can you be more specific here?

We can't move because we can't even start to move the solutions. We can't move things to libraries on the new system and migrate over in any reasonable way, because the build system won't build both. And there's a big mismatch on server build tools and what Visual Studio does here (see the fights we had with it above). Side note: those server build tools aren't labelled with a version.

Yes this is true and I don't see this changing for a while. Changing all of the old things to the new project system will take years. Certain project types will be easier than others but it's not easy changing them all with full parity

Sure, but this isn't asking for full parity on day one. By removing the biggest blockers to starting migration on the way to parity, we can parallelize a lot here and end up with ASP.NET Core far sooner.

That's absolutely false, that was never said.

I'm fairly certain this was said in a community standup around the time all the changes were happening as the current thinking. If that's changed then great, but we've got no newer information AFAIK.

What are the big things you are struggling with at the moment?

I'm assuming you mean in trying to make this work. Building (on a server, not in VS) and debug launching are the big 2.

Why is supporting is ASP.NET 4.x with an SDK project a stepping stone to ASP.NET Core support?

Because you can't mix both styles in the same solution and have the tooling work (at least today). The project files are massive today (no globs), so it's a big bang change to move everything over. It also means we can't move to anything with the dotnet build system. dotnet build and dotnet msbuild both go boom with these project types.

Why can't you use both ASP.NET Core and ASP.NET in the same solution?

See above.

Do you have .NET Standard libraries that are shared between old and new?

We want to, but again, see above. The only things we can share are completely external to the solution (e.g. MiniProfiler, StackExchange.Redis, Exceptional, Jil, protobuf, etc.). Moving code outside of the solution that belongs to it in order to make the builds work would make dev time take even longer (e.g. unnecessary packages, publishing, and build time for every minor change).

Can you list out some of the pains you have migrating (any pains really)?

The above covers it mostly. We can't use dotnet msbuild to build solutions if they contain old project types, so we can't go there. We can't use globs because VS will replace them. And crashing on every project reload is just maddening, since it takes 60-120 seconds per restart of Visual Studio for it to becomes responsive again. I'd estimate at this point in time I'm losing about 30 to 40 minutes a day on Visual studio locking up (for over a minute at a time) or restarting due to a crash. And losing project file changes when it does that.

I'm happy to work with someone and send our solution over (NDA style) if it'll help.

@davkean

This comment has been minimized.

Copy link
Member

@davkean davkean commented Oct 1, 2017

@NickCraver I've reached out to you privately on the crash you are experiencing. The long delays are likely caused by a mix of slow design-time builds + the fact that we block the UI while waiting for them in the legacy project system. This experience should be much better in 15.5 as we've done some performance here to reduce the number of builds we do during solution load/reload/configuration change. If you have custom targets, I'd use the steps called out in the doc to make sure that they aren't increasing your design-time build time. Performance work we're doing for .NET Standard/.NET Core scenarios will also benefit these builds for legacy scenarios.

Our intention, long term, is to have feature parity with the legacy project system, however, our biggest focus for the next couple of updates is to improve the performance and reliability of the existing scenarios we've already bitten off.

Can you expand on the the "all or nothing" argument? You can continue to call msbuild solution.sln on solutions that have a mix of both legacy format and sdk-based format. Moving over to dotnet build isn't a requirement. Is it because you don't want to update the build server?

@davidfowl

This comment has been minimized.

Copy link

@davidfowl davidfowl commented Oct 2, 2017

I'm fairly certain this was said in a community standup around the time all the changes were happening as the current thinking. If that's changed then great, but we've got no newer information AFAIK.

Nope, it was never said and nothing changed.

Correct, talking about this area. is a great concept, but broken in the older world. It took us a full day to get a build setup and working on and decided against attempting it with any further ASP.NET non-Core projects. We can use it in libs, that's it.

It would be good to get more feedback here. Was the entire experience just error prone or were there specific issues?

We can't move because we can't even start to move the solutions. We can't move things to libraries on the new system and migrate over in any reasonable way, because the build system won't build both. And there's a big mismatch on server build tools and what Visual Studio does here (see the fights we had with it above). Side note: those server build tools aren't labelled with a version.

Like @davkean asked, why can't you even begin to move? MSBuild 15 supports both old and new project types AFAIK, you can't use dotnet build but msbuild should work. If the build tools don't have an msbuild 15 equivalent then we suck and should have that.

Sure, but this isn't asking for full parity on day one. By removing the biggest blockers to starting migration on the way to parity, we can parallelize a lot here and end up with ASP.NET Core far sooner.

The issue is asking for "support" we can't add a fraction of the features and claim support. Support means full parity. Like I asked before, knowing what specifics are absolutely blocking you from beginning the migration would be extremely useful.

Because you can't mix both styles in the same solution and have the tooling work (at least today).

This is the real crux of the issue. We need to figure out why this isn't working. Can you list out the issues with this? This absolutely needs to be fixed because this is key to people migrating existing solutions.

The project files are massive today (no globs), so it's a big bang change to move everything over. It also means we can't move to anything with the dotnet build system. dotnet build and dotnet msbuild both go boom with these project types.

This isn't new and shouldn't be a blocker. MSBuild should work like it always did with both existing and new style SDK projects.

We can't use dotnet msbuild to build solutions if they contain old project types, so we can't go there.

Can you just use the latest msbuild on windows?

We can't use globs because VS will replace them.

This isn't new and I don't see how it's a blocker. Over time more projects will likely be converted when full parity can be reached, but it's not a short term thing.

@jmarolf

This comment has been minimized.

Copy link
Member

@jmarolf jmarolf commented Oct 2, 2017

Correct, talking about this area. is a great concept, but broken in the older world. It took us a full day to get a build setup and working on and decided against attempting it with any further ASP.NET non-Core projects. We can use it in libs, that's it.

Adding @tmeschter. This sounds like a bug in PackageReference that we should fix. @NickCraver can you describe what the issue is in more detail?

@NickCraver

This comment has been minimized.

Copy link
Member Author

@NickCraver NickCraver commented Oct 2, 2017

@davkean @jmarolf

I've reached out to you privately on the crash you are experiencing.

Thanks! I've followed up and have many dump ready to send from hangs, stalls, and just-before crashes today.

Can you expand on the the "all or nothing" argument? You can continue to call msbuild solution.sln on solutions that have a mix of both legacy format and sdk-based format. Moving over to dotnet build isn't a requirement. Is it because you don't want to update the build server?

We have no problem updating the build servers (we control them all), but updating to the latest MS Build tools released we never got to work. We were deploying manual target directories and overrides to get web applications working. To make a single project work, we ended up copying all targets from local installs over to a directory on each build server and overriding the targets path in MSBuild. The new build tools installed fresh did not work for web applications (missing their targets).

On the mixing: we could never figure out how to build it. See opserver/Opserver@7ccf72f for similar issues on finding MSBuild itself. dotnet build is a great advancement to all these things (e.g. tremendously simplified builds), but is completely unusable for most current scenarios.

The major blocking problem we had (I'll have to re-attempt this with another solution to fully document as we go, trying from recall here) was various breaks on the new project system with old references. All the tooling either created or expected <PackageReference>, or we ended up with 2 very different references on the machine since these 2 cannot point to the same DLLs. Our private projects cannot use <PackageReference> if they contain references to our authenticated NuGet feeds (the long standing reason we have to check in /packages). Almost all projects have such references. I admittedly last tried mixing <PackageReference> and old style path references in a solution 3 previews ago, but I haven't heard of any changes here, or even whether this is an expected scenario. NuGet tooling doesn't seem to expect this scenario I'm guessing.

In short, there are several areas where bridging old and new worlds is painful or just something we couldn't make work. The authenticated feeds issues is hard for me to demonstrate in open source, unfortunately.

@NickCraver

This comment has been minimized.

Copy link
Member Author

@NickCraver NickCraver commented Oct 2, 2017

@davidfowl Thanks for the replies, follow-ups:

Nope, it was never said and nothing changed.

Fair enough, if so that's my mistake, I swore this was said off-hand but maybe it wasn't by the team. My fault.

If the build tools don't have an msbuild 15 equivalent then we suck and should have that.

I'm honestly not sure what the contain. 15 to 15.3 had breaking changes you needed a newer version for, and installing the latest didn't work. I'll try a single new project in the SO solution soon as I'm able (likely next week, we're busy as hell atm) and better document step by step what breaks. See above response for some of the issues I can recall right now.

The issue is asking for "support" we can't add a fraction of the features and claim support. Support means full parity. Like I asked before, knowing what specifics are absolutely blocking you from beginning the migration would be extremely useful.

Again see above. Note: we're not asking for support (the official term), only bits that would unblock many. We built Stack Overflow on an MVC beta, test SQL in CTP in production, etc. no strangers to pre-release bits on the way to supported.

This is the real crux of the issue. We need to figure out why this isn't working. Can you list out the issues with this? This absolutely needs to be fixed because this is key to people migrating existing solutions.

Yep, above. I'll do a full doc run on an SO branch with the current preview and build server tooling to see what we hit today (AFAIK nothing has changed, we were on the latest build server tooling on the last attempt), and write up what we're hitting. I don't want to mis-file a dozen issues though, how about I file a big one and we break it out into areas as you guys and gals see fit? If so: which repo?

Can you just use the latest msbuild on windows?

I think so, but these aren't versioned like they need to be IMO. I'm both a developer and a sysadmin, and the sysadmins here are frustrated at the tooling downloads. For example go here and scroll to the bottom: https://www.visualstudio.com/downloads/ It's an unversioned installer (that needs an update immediately after downloading by the way, not an awesome experience). Since it's unversioned, we have to make some assumptions about which version is installed or blindly update it (current approach) which led to some mismatches of 15.0 vs 15.3 msbuild installs. Just for fun, it's not in the registry anymore either, so we have to install a whole other project just to find it (vswhere), and I guess check that into git or PATH it on every server (is this sounding crazy yet to do a simple build? it is to me).

In the old world we could at least find where MSBuild is in the registry (in a PowerShell build script) and move along. Now even that's regressed. This isn't an issue if you're using dotnet build, but is if you need actual full msbuild. I consider this a regression, you now need extra tooling just to find MSBuild.

But yes, we're free to use the latest version of MSBuild. Actually figuring out how to do so, which version is installed or where it is are all different questions we don't always know the answer to.

This isn't new and I don't see how it's a blocker. Over time more projects will likely be converted when full parity can be reached, but it's not a short term thing.

That's unfortunate. When we heard about the new project system it was the thing we were all excited about, because it results in the most pain. From an outside perspective (and maybe mine's way off) I don't believe that new project system being only for new projects/types was communicated well at all. It was a major let down to realize this was the case and now will be for quite some time.

Still, I'll help debug here where I can but admittedly have practical time limits on fighting tooling vs. getting any work done. Most of this is done on my personal time at the expense of our OSS getting any love.

@tmeschter

This comment has been minimized.

Copy link
Contributor

@tmeschter tmeschter commented Oct 2, 2017

@NickCraver

  1. I'd like to hear more about the issues you've had with <PackageReference> on the old project system as I implemented that. :-)
  2. I'm also interested in any crashes that occur in VS 2017 when using the old project system. In general I would expect 2017 to be more reliable in this area, and regressions are a high priority.

Feel free to ping me directly at tom.meschter@microsoft.com.

@jmarolf

This comment has been minimized.

Copy link
Member

@jmarolf jmarolf commented Oct 3, 2017

@NickCraver regarding the other issues:

  1. MSBuild tools does not include the targets to build web projects
  2. Unable to locate MSBuild on build server.

The first issue sounds like a bug, but I'm confused. It looks like you can install the web targets:
image
@NickCraver does this not work? I understand automated installation of this installer leaves some things to be desired but the following command should work

vs_BuildTools.exe  --layout c:\vs2017buildtools --includeOptional --lang en-US

Giving you a folder (C:\vs2017buildtools) with vs_BuildTools.exe that you can copy and install on any machine. while guaranteeing a known version Is this not what you are doing?

The second issue is a general problem with everything in vs being harder to find because you can now install vs anywhere. However, you can control where things get installed on your build server. If you always install the build tools to C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools msbuild will always be under C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\MSBuild\15.0\Bin

@NickCraver

This comment has been minimized.

Copy link
Member Author

@NickCraver NickCraver commented Dec 1, 2017

@jmarolf Here's what we ended up with to get building and not have gigs of extras to maintain and update (lengthening patch times). Tooling offline creation:

.\vs_BuildTools.exe  --layout \\path --includeOptional --lang en-US
  --add  Microsoft.VisualStudio.Workload.NetCoreBuildTools 
  --add  Microsoft.VisualStudio.Workload.WebBuildTools
  --add Microsoft.VisualStudio.Workload.MSBuildTools
  --add Microsoft.Net.Component.4.6.TargetingPack

Server install/update:

.\vs_BuildTools.exe --includeOptional 
  --add  Microsoft.VisualStudio.Workload.NetCoreBuildTools
  --add  Microsoft.VisualStudio.Workload.WebBuildTools
  --add Microsoft.VisualStudio.Workload.MSBuildTools
  --add Microsoft.Net.Component.4.6.TargetingPack
  --noWeb 
  --passive

The second issue is a general problem with everything in vs being harder to find because you can now install vs anywhere. However, you can control where things get installed on your build server.

Sure, I agree. But in open source we don't control the build server. Thousands of people control thousands of build servers.

This week we've had several major issues with Stack Overflow (including 2 outages) rooted in bad .csproj merges that could have been globs for the past decade if the tooling stopped expanding this. Is there any hope of not expanding globs at least being supported on the old system? We're far from the only ones hitting this. Or is the stance this is so far into the future it'll never happen and I should just close the issue?

@Pilchie

This comment has been minimized.

Copy link
Member

@Pilchie Pilchie commented Dec 1, 2017

We don't currently have work to support not expanding globs in the old project system on our radar. Instead, we'd like to eventually be able to open old style projects with the new project system without also needing them to be converted to SDK projects.

@NickCraver

This comment has been minimized.

Copy link
Member Author

@NickCraver NickCraver commented Dec 3, 2017

@Pilchie As an illustration of why this matters:
Our main project (StackOverflow.csproj) using only globs goes from 13,307 lines down to 1,537 lines. Of those 1,537:

  • 900 are view/model nesting we use (this could be 1 pattern if #159 gets in)
  • 363 are refs.

With <PackageReference> (which we can't use due to NuGet server issues yet - unrelated to this issue), that 363 goes down to 122 lines.

So any, with globs something we experience merge pain with multiple times a week goes to nothing. I looked through our git history and I believe we would have had a merge conflict only once in the past 6 years (one simultaneous lib update race) in our main .csproj. That's a huge impact to our daily lives and to the stability of our code, application, and sanity.

Please, reconsider some measures to improve life for all of the developers who are dealing with ASP.NET non-Core and will be for the foreseeable future. There are millions of us and eventually is a long time.

This is by far the highest voted issue in this repo, so I'm curious: how is work and feedback prioritized? The User Voice forums for Visual Studio are, and I don't think I'm being extreme here, a wasteland. They're not maintained, there's a lot of duplication, and User Voice has no mechanisms for keeping up with issues. While problems are getting love in the new developer community site, missing things (like this) are closed as non-problems and the customer avenues for making suggestions are pretty grim. It's not specific to this issue, but as this is by far our biggest desire to improve every dev here's daily life, I'm asking.

Note that Visual Studio is crashing on .csproj changes/reloads on a git pull more often than ever. I'm seeing many of my teammates experience this on hangouts several times a day. So this issue (or even just globs) would have a very significant impact on developer frustration (by not prompting for reloads). We're seeing new project types get support and love while those of us in the old world are just crashing. It's very demotivating to hear "eventually" on improvements while this trend is continuing.

Please, please prioritize this.

@mduu

This comment has been minimized.

Copy link

@mduu mduu commented Dec 3, 2017

If I have to vote for one single thing, I like to get rid of all the individual file-references in our MVC5 project files (and class-libraries). They result in merge-conflicts in every other PR.

Note: we can't move to .Net Core for the next years as our hoster/customer (federal gov.) does not have any plans to support .Net Core yet. That will take years then.

@davkean

This comment has been minimized.

Copy link
Member

@davkean davkean commented Dec 3, 2017

@NickCraver The crash when the csproj reloads we should look at. You've mentioned this before but I'm yet to see feedback reports from your team about it - can you get them to individually report issues (you don't need to catch the crash, just report that it occurs) and we'll go through the watson reports to see what the underlying cause is?

Understand the pain here here with merging, but as @Pilchie mentioned we have no intention of supporting globs in the old project system. The work there is much harder than the new project system due to it being native (and we have double-wrap all the new globbing-based APIs from MSBuild) and unlike the new project system it has its own in-memory model of the project separate to the MSBuild model. We would rather spend that time and resources on adding features to the new project system that will enable you to move your existing projects over to it.

@willl

This comment has been minimized.

Copy link

@willl willl commented Nov 30, 2018

@YakhontovYaroslav You can use msbuild /restore in place of msbuild /t:restore and msbuild /t:build if I understand what you're trying to achieve.

You'll need to have msbuild 15.5 installed for it to work. See: microsoft/msbuild#2455 (comment)

@304NotModified

This comment has been minimized.

Copy link

@304NotModified 304NotModified commented Dec 4, 2018

@davkean

This comment has been minimized.

Copy link
Member

@davkean davkean commented Dec 4, 2018

Thanks for the feedback and votes. Our number 1 priority for the new project system in the VS 2019 timeframe is support client scenarios. In particular, Windows Forms and WPF designers and related features, for both .NET Framework and .NET Core. As we make progress on those commitments and start thinking about what we want to bite off for the future, we will factor in the above feedback.

@CZEMacLeod

This comment has been minimized.

Copy link

@CZEMacLeod CZEMacLeod commented Dec 6, 2018

@davkean In your list of priorities for VS2019 feature parity is the first thing listed, yet ASP.NET (non-Core) (e.g. this issue) isn't even tagged as a parity legacy issue. While I understand that many desktop developers are 'in-the-cold' until .netcore 3 and WF/WPF/XAML come to the table, it would be nice to address the (minor) needs of those working on maintaining, and developing with ASP.NET.
Given that there are already a good number of 'workarounds' in place even in this thread, it seems to me that the minimal amount of VS IDE support required for launch settings, and razor intellisense support most of which you already must have code for, just not lit up under the new project system, seems disappointing.

@davkean

This comment has been minimized.

Copy link
Member

@davkean davkean commented Dec 6, 2018

yet ASP.NET (non-Core) (e.g. this issue) isn't even tagged as a parity legacy issue.

My bad, tagged it.

Understand the disappointment, but at the end of the day like all software projects, we need to prioritize what we're going to focus on. For the first few updates of VS 2019, given we're on the hot path for .NET Core 3.0, we'll be focusing on WPF/WinForms. I've already investigated legacy Razor support, and it is non-trivial given our integration with Roslyn is very different to the legacy project system.

If folks want to split out feature support into separate issues that would make ASP.NET/MVC dev easier on top of the new project system, I'm happy to take at look at each feature in isolation and maybe we can take contributions or sneak them in between our current priorities, but at the moment it's not clear in mind what exactly "ASP.NET support" means in terms of actual features without doing a deep dive into it.

@wanton7

This comment has been minimized.

Copy link

@wanton7 wanton7 commented Dec 6, 2018

This also very annoying for our company. We have all other projects in new csproj format. Biggest problem is that Razor can't see any changes in other project until you compile them and we have all our models in project that is in new csproj format. Plus if you hit F12 in Razor it goes to metadata and not to actual source code in other project. Not to forget lot of time you get errors in error window and in editor from Razor views about missing assemblies, but those Razor views work just fine.

@NickCraver

This comment has been minimized.

Copy link
Member Author

@NickCraver NickCraver commented Dec 6, 2018

Biggest problem is that Razor can't see any changes in other project until you compile them and we have all our models in project that is in new csproj format. Plus if you hit F12 in Razor it goes to metadata and not to actual source code in other project.

Yes. This is insanely annoying. It makes it look like a half-finished feature. It's not seamless, it's incredibly annoying, and it will cost us a lot of debug time. We're about to move all the Stack Overflow models out to another project in order to make the ASP.NET project as small as possible for an ASP.NET Core move later. But our options are: A) deal with what design-time things are broken builds and the inability to navigate source between the two. Or B) just ignore than the new project system exists.

We'll have to choose B so that the other devs don't murder me in the migration process. But this also means we can't multi-target and ensure we're even netcoreapp or netstandard compatible along the way, which is the entire point of moving this code ahead of time. I'm incredibly frustrated to see this indefinitely punted.

@davkean

This comment has been minimized.

Copy link
Member

@davkean davkean commented Dec 6, 2018

We're tracking this via #3010, this is something I can see us tackling sooner rather than later. Can you make sure that bug captures all the issues you are running into around this?

@bergmeister

This comment has been minimized.

Copy link

@bergmeister bergmeister commented Dec 11, 2018

@davkean I have to add one more issue to add to this: I can manually migrate an ASP.Net project to Packagereference and it works and VS shows the packages in References of the Solution Explorer but when using Manage Nuget Packages on the project or solution, the packages are not visible, which makes it impossible to use because then we cannot consistently update all our projects (which wouldn't be an issue if there was a built-in way to central manage packages in a solution that also works with the UI). I am using the latest released VS version 15.9.3

@Pilchie

This comment has been minimized.

Copy link
Member

@Pilchie Pilchie commented Dec 11, 2018

when using Manage Nuget Packages on the project or solution, the packages are not visible

@rrelyea - any ideas about this?

@bergmeister - I'd suggest a new item on https://github.com/NuGet/Home for this.

@chucker

This comment has been minimized.

Copy link

@chucker chucker commented Dec 11, 2018

Isn’t that exactly the reason the packages.config migration UI doesn’t show up on ASP.NET projects?

@bergmeister

This comment has been minimized.

Copy link

@bergmeister bergmeister commented Dec 11, 2018

@chucker No, the migration UI is only disabled because all generic cases are not covered yet, however there are still plenty of cases where one can migrate due to the features of the ASP.NET project being used (in this case an Angular project)

@jjmew jjmew added Triaged and removed Triaged labels Jan 14, 2019
@fredericDelaporte

This comment has been minimized.

Copy link

@fredericDelaporte fredericDelaporte commented Feb 8, 2019

I also wish the support of non core Asp.Net projects as a SDK project format, mainly for the sake of using globs. For my case, what I am lacking most when attempting to use the new format is full Intellisense support in dynamically compiled files.
Yes, I mean those things under App_Code folder, or aspx/aspx.cs included as content with the .cs referred through CodeFile attribute instead of CodeBehind. Although supposed to be used with the old "web site" project (no project file), they are also supported in web application projects (old project file).
But with SDK projects, even with @YakhontovYaroslav solution, there is no auto-completion available in dynamically compiled files excepted for things defined in the same file or, for aspx/ascx/master files, in their matching .cs.

I do not really expect this very old feature to be supported by the IDE with the new csproj format. But having instead globs available for the old format would be very welcome.

(By the way, using Microsoft.NET.Sdk.Web SDK is worst than Microsoft.NET.Sdk when your project also contains .asp files (yes, Classic Asp...): with the former, their contents do not show up anymore with the "HTML (Web Forms) Editor".)

@304NotModified

This comment has been minimized.

Copy link

@304NotModified 304NotModified commented Feb 8, 2019

FYI,

currently this issue has 188 votes, the 2nd has 24 votes...

@304NotModified

This comment has been minimized.

Copy link

@304NotModified 304NotModified commented Feb 8, 2019

Originally posted by @davkean in #2670 (comment):

If folks want to split out feature support into separate issues that would make ASP.NET/MVC dev easier on top of the new project system, I'm happy to take at look at each feature in isolation and maybe we can take contributions or sneak them in between our current priorities, but at the moment it's not clear in mind what exactly "ASP.NET support" means in terms of actual features without doing a deep dive into it.

--> #4557

@IanKemp

This comment has been minimized.

Copy link

@IanKemp IanKemp commented Feb 18, 2019

@304NotModified Aaand it's Closed. :(

@davkean

This comment has been minimized.

Copy link
Member

@davkean davkean commented Feb 18, 2019

@304NotModified To update the thread. Our priorities have not changed, we are still focused on client scenarios for .NET Core 3.0 with the new project system for the first lot of updates for VS 2019. We will continue to make performance improvements to the legacy project system, but we will not port big new features to it. We did an investigation this time last year for globbing in particular, and it is significant cost that does not help in the direction of replacing it.

For some good news, we've fixed Razor "Go to definition" breaks when target is defined an SDK-style project in VS 2019 Preview 4, which improves the interopolitity between the two. Please tell us if you hit more issues like this.

@fredericDelaporte Can you file an issue on the IntelliSense code behind? Let's treat that as a separate issue. @bergmeister Did you file a bug against NuGet on that package reference issue? I've been unable to repro this.

@kelps

This comment has been minimized.

Copy link

@kelps kelps commented Apr 4, 2019

Ok, here is another example: at our company we have a solution composed of several projects. One is the UI, a web forms application (for legacy and extensibility reasons at our clients, we can't go full MVC just yet).

Since each project has a very specific concern, we planned to have each house their own server controls and embed any necessary user controls (.ascx). We'll be using the virtual file provider in ASP.NET to get the embeded user controls.

Problem is, like @fredericDelaporte mentioned, with SDK style projects, I can't make the intellisense and code behind files (*.ascx.designer.cs) work at all. It works just fine if I try the exact same thing in a regular class library. Here are my steps:

  • Add > new file > mycontrol.ascx (I used Shift + F2 in this case from Mads "Add file" extension because .ascx and .aspx are not available in non web application projects)
    • change that to be a Embeded Resource, instead of Content
  • Add > new file > mycontrol.ascx.cs
    • edit it to be a partial class and inherit from the appropriate class
  • Add > new file > mycontrol.ascx.designer.cs

If I do this in a regular class library, the code completion works just fine in the ascx file and the .designer file is generated and updated as expected. If I do this exact same steps in the SDK style class library (targeting the same .net framework), neither the code completions in the ascx nor the code behind work.

I even tried to edit the file to create and add the subtype to the files in the same way the regular project does, but it didn't work either.

Is there any way, even if somewhat manual, to make this file types work? Maybe register the custom tool manually? Or is this really something that the VS does and we can't really make it work at all?

Having a simplified file project is amazing and we really don't wish to go back if we can avoid. So much better not to have unnecessary merge conflicts.

@weitzhandler

This comment has been minimized.

Copy link

@weitzhandler weitzhandler commented Jul 23, 2019

Hi guys,
I have an old deployed ASP.NET project, that I need to start taking care of.
All we have is the wwwroot folder.
What we need to do is to recreate a VS project so we can debug it.

How can I recreate a new project from an old deployed wwwroot folder?

Thanks a lot!

@maxinfet

This comment has been minimized.

Copy link

@maxinfet maxinfet commented Oct 11, 2019

@davkean In regards to this comment

If folks want to split out feature support into separate issues that would make ASP.NET/MVC dev easier on top of the new project system, I'm happy to take at look at each feature in isolation and maybe we can take contributions or sneak them in between our current priorities, but at the moment it's not clear in mind what exactly "ASP.NET support" means in terms of actual features without doing a deep dive into it.

I would be willing to go through the default templates and put them on the new project system and see what features I am aware of work and don't work. Is this typically how someone on your team would do this investigation or do you have sources that would give a better idea of what features you are looking for to see if they work?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
You can’t perform that action at this time.