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

Nuget and MVC 6 #1128

Closed
Eonasdan opened this issue Jun 16, 2015 · 21 comments
Closed

Nuget and MVC 6 #1128

Eonasdan opened this issue Jun 16, 2015 · 21 comments
Milestone

Comments

@Eonasdan
Copy link
Owner

In the new MVC 6 project client slide libraries like this are no longer meant to be delivered via Nuget. At some point the Nuget packages should be discontinued in favor of bower deliver (somewhat ironically given my previous comments about not using bower).

I want to continue to support older projects and I'm sure the number of early adopters will be much fewer in number than those who use Nuget for everything.

That said, is there any reason why we could not put an End of Life date on the Nuget packages?

.Net devs do you use nuget outside of MVC?

@ghost
Copy link

ghost commented Jun 16, 2015

Hi - nuget is the standard delivery tool for pacages using Visual Studio.

@Eonasdan
Copy link
Owner Author

I know that. I'm a .Net developer. However, as I said, MVC 6 won't use (or will have diminished used) for delivering front-end scripts like this.

@fchiumeo
Copy link

Hi
I'm using Nuget for backend libraries(EF,Autofac,AutoMapper, etc ..), bower for frontend libraries(bootstrap, jquery, datatables, this library, etc..) and npm for validate CSS,JS and build for deploy

@Eonasdan
Copy link
Owner Author

@fchiumeo then your process will not change at all

@fchiumeo
Copy link

"fit" for what's coming with the new visual studio and it turned me more comfortable having separate the frontend and backend libraries

@Untit1ed
Copy link

Nuget really sucks for client-side libraries. I think most of asp.net devs already use bower.

@Eonasdan
Copy link
Owner Author

I think an EoL for the nuget packages should be next year (2016) or 2+ major version (7) which ever comes first.

Is that too long?

@Untit1ed
Copy link

I think you're overthinking it. Just stop updating it for the new v5. People will find a way to get the library, since most of the stuff is not on nuget anyways.

@Eonasdan
Copy link
Owner Author

You're probably right, I probably am overthinking it.

@Eonasdan Eonasdan added this to the 5.0 milestone Jun 30, 2015
@Eonasdan Eonasdan mentioned this issue Jun 30, 2015
@Jogai
Copy link

Jogai commented Sep 18, 2015

Well, I think it would be nice if devs could take unsupported libraries off nuget. There are too many stale packages.

@TrabacchinLuigi
Copy link

i do use nuget for everything, i think if this is the road mvc is taking i will take it too, actually i hope bower will solve some issues i have using tfs and all the libraries files getting checkedin and getting me crazy.

@fchiumeo
Copy link

fchiumeo commented Oct 2, 2015

@TrabacchinLuigi I have all front end components in bower, use gulp for task, i.e. validate js, css and one task copy necessary files from bower_components to js/lib folder and check in lib folder to tfs

@TrabacchinLuigi
Copy link

i've tried that, and i lost so much time trying to make it work i think i will just download and put the files where the hell i want

@fchiumeo
Copy link

fchiumeo commented Oct 3, 2015

@TrabacchinLuigi Try it

@Jogai
Copy link

Jogai commented Oct 5, 2015

Thats what I do, only a little bit different. (Will fail if packages changes their folder structure...)

    gulp.task('copyJs', function () {
        var requirejsOptimize = require('gulp-requirejs-optimize');
        return gulp.src([
            'node_modules/eonasdan-bootstrap-datetimepicker/src/js/bootstrap-datetimepicker.js',
            'node_modules/eonasdan-bootstrap-datetimepicker/build/js/bootstrap-datetimepicker.min.js'])
            .pipe(gulp.dest('Scripts'));
    });

@Eonasdan Eonasdan closed this as completed Jan 4, 2016
@sguryev
Copy link

sguryev commented May 5, 2016

It seems that I have missed something. MVC 6 (actually ASP.NET Core) is under the RC1 version (not RELEASE yet). Actually from November 2015 (https://github.com/aspnet/Home/wiki/Roadmap)

So I want to know what will be with the ASP.NET 4.5 projects? Which is actually the latest version could be used for the Production.

@Jogai
Copy link

Jogai commented May 10, 2016

@sguryev You can use gulp already in visual studio, and I recommend it. Its the way forward, and one thing less to learn when you eventually are going to use MVC 6.

@sguryev
Copy link

sguryev commented May 10, 2016

@Jogai I support 3 projects on ASP.NET 4.5. They are worked on PROD. Are you really suggesting me to switch them to the Bower and Gulp? Am I right that Gulp is "the streaming build system" and Nuget is a package manager (like Bower for example).

Do you know that Bower package manage UI works incorrectly in the VS2015U2 (black unrecognizable font for the dark theme + poor packages info + wrong package versions). This is my first experience with the Gulp+Bower in the ASP.NET Core.

image

And this problem not only with the Bootstrap package. You can check yourself.

image

So I think that Bower is too raw in the VS and no one will agree to switch from Nuget to Bower for the old projects. It means that they will have to use old versions or update it manually.

@Eonasdan
Copy link
Owner Author

The decision is made. The nuget packages won't be updated to the next major release. Either use a CDN, v4, bower or npm.

@Jogai
Copy link

Jogai commented May 11, 2016

@sguryev My suggestion is to learn the tools and gain the skills. Using it in existing projects is entirely up to you, and depends on a lot of other factors.

In my current project I'm only using NPM + Gulp, and I dont use the extenstion to manage the packages via the UI (that would be https://github.com/madskristensen/PackageInstaller/ I think)

And its not about switching from Nuget. I like to use Nuget for server-side technologies, and npm for front-end libs. In my experience there are more front-end libraries on npm, and they're more up-to-date.

and no one will agree to switch

No one in your team I presume?
Further info:
https://www.google.com/trends/explore#q=Bower%2C%20NuGet%2C%20Npm
http://webtooling.visualstudio.com/
https://www.simple-talk.com/dotnet/asp.net/introduction-to-bower,-grunt,-and-gulp-in-visual-studio/
http://blog.chrisbriggsy.com/Migrate-from-nuGet-to-Bower/
Keep in mind, always choose and pick what is best in your own situation, as I said, I'm not even using bower or the package manager extension as mentioned in some articles.

@sguryev
Copy link

sguryev commented May 11, 2016

@Jogai thank you for your suggestion. But enterprise projects are not the place for learning.

No one in your team I presume?

No one from enterprise project managers.

I'm new to all this stuff and use what the default template suggests me (ASP.NET Core I mean). NPM for utils packages management, Bower for client-side packages management, Gulp - just a tool to make some transformations over static files. I have never seen how to use the NPM for the client-side packages instead of the Bower. Thank you for the URLs I will review them.

I'm not even using bower or the package manager extension as mentioned in some articles.

And in the start post from @Eonasdan

@ghost ghost locked and limited conversation to collaborators Jun 17, 2017
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

6 participants