I have Microsoft.VisualStudio.Web.CodeGeneration.Design nuget in a project.
Can it be safely excluded from publishing (<ExcludeAssets>runtime</ExcludeAssets>)?
Is there scenario, when during runtime, code has dependency on this package?
As I understand this package is used only for generating the code during development.
I don't see any reason to add its dll in published code.
Is it safe to exclude Scaffolding packages from publish version?
As the package describes,
Code Generation tool for ASP.NET Core. Contains the
dotnet-aspnet-codegenerator command used for generating controllers
and views.
It only works for generating code for views or controllers during developing and the project itself does not depend on the package at runtime.
So it is safe to exclude that nuget package from publishing using your method. And you do not have to worry too much about it.
I have a .NET Core console app and a .NET Standard library. The app consumes the library via a nuget source in RELEASE, and a project reference in DEBUG, via a Condition on each ItemGroup.
This is working great locally, as I can make changes and test both the library and the app in parallel. When the sources get committed (obviously the library before the app), the library gets published, and the app consumes the published package.
Now, this app is also one piece of a docker-compose, and I want to be able to debug while running in Docker. This is perfectly supported with Visual Studio, but it also means my app is built against the library package available in my nuget source, not a locally-compiled and debuggable one.
I do have clues as to how to work around this, but would like to know if I'm just not either missing something, or trying to reinvent the wheel (though I really like new wheels).
I could copy the library's sources and project as part of the Dockerfile, and make sure it respects the Condition within my app's csproj. This sounds patchy.
I could have a local folder within the app sources where I copy the freshly built library's .nupkg, which would be copied via Dockerfile before dotnet restore, and also mentioned in the Nuget.Config, but ignored in .gitignore.
I'm about to try #2. Is there a simpler approach?
Thanks.
So I have Umbraco v6 currently setup via a release download and split into a class library and a website. I need to upgrade to v7 at some point and have some question on how I should setup.
What are the pros/cons of setting up through Nuget vs Downloading source and creating project?
Devin
The pro of using nuget is that you don't have to build the project from scratch. If you have a need and/or desire to understand how umbraco is built, by all means pull down the source code, but if you just want to use umbraco, and customized it thru the hooks it provides, then the nuget packages will be easier.
I've done both (though not with the latest version), and using nuget is far easier and quicker to get going.
Tools such as Bower, Grunt and Yeoman have surged in popularity recently.
Whenever I've read about them or come across them in an article, I've dismissed them as tools used for Mac-based front-end devs or PC-based but not on the Microsoft stack - Sublime Text etc.
Visual Studio has NuGet, project templates, MSBuild, MSDeploy, TeamCity/TFS Azure etc. and I generally consider VS has being a very highly automated ecosystem (some say it makes us productive at a cost of understanding).
How are these tools being used by ASP.NET devs on VS?
Note: This is not an opinion-based question, I'm looking for real-world examples of how these tools are being used.
There is a Package Intellisense extension for Visual Studio which adds bower and npm package support
Grunt/Gulp launcher extension for launching grunt/gulp tasks
Read this awesome article written by Scott Hanselman for more info:
http://www.hanselman.com/blog/IntroducingGulpGruntBowerAndNpmSupportForVisualStudio.aspx
UPDATE:
These features are now fully integrated into Visual Studio 2015:
http://www.asp.net/vnext/overview/aspnet-vnext/grunt-and-bower-in-visual-studio-2015
Great tips from john papa:
http://www.johnpapa.net/get-up-and-running-with-node-and-visual-studio/
As per Scott Hanselman's blog posting, he says this about the reason why a VS dev might want support for these tools:
Some of you may ask, why not use NuGet for JavaScript? Why not extend
MSBuild for building CSS/JS? Simple. Because there's already a rich
ecosystem for this kind of thing. NuGet is great for server side
libraries (and some client-side) but there are so many more CSS and JS
libs on npm and bower. MSBuild is great for server-side builds but can
be overkill when building a client-side app.
So, use both. These are tools in your toolkit. Adding support for
Gulp, Grunt, Bower, npm (and other stuff, in the future if needed)
means a more familiar environment for front-end devs doing ASP.NET and
it opens the doors for ASP.NET devs to bring in the JS and CSS
libraries communities use every day.
Though I'd still be interested in other people's take on how these tools fit in to the 'workflow' of a VS developer. For example, "Before I installed Grunt, I wasn't able to easily... blah."
Update
I'll stick some updates in here as I learn things.
So, new learning no.1: Yeoman scaffolds front-end, client-side code. Whereas VS scaffolds server-side stuff and project templates (that don't change for months/years), Yeoman can help with boilerplate for fast-changing JS MV* frameworks, for example.
New learning no.2: the tooling is not ready for prime-time enterprise dev.
The first problem is that npm downloads dependent packages into nested subfolders and recurses this model exhaustively, so you end up with folder paths that are 100s of characters long. Windows and some tooling goes nuts. There are workarounds but its a serious flaw.
Latest Node and some added command line options now make this better behaved.
Developers running Windows are often in enterprise settings which means proxy filters and auth. For me, I needed to install Cntlm local proxy to get NPM and other tools to work via our proxy, which violates our IT policy, I just didn't tell them.
Some of NPMs packages seem to want to clone Git repos using SSH! Port 22 is not open; because the community is so Linux/Mac non-enterprise oriented, such issues arise because they're not a problem for so many creative-agency devs and then can hang around for months.
New learning no.3: how dynamically downloaded JS files end up as content in the project file and thus added to an MS Deploy package is still an unknown.
Update on learning 3, we created a build that just transformed the config files, then we used the MSDeploy command line to copy files individually to the destination server. Not something I'd do if I were working alone, it took weeks on and off, to automate all this.
With Bower updates are faster. Every time a new version or update is released we can easily find it in Bower. You no longer have to wait as we had to with NuGet.
So we could say that NuGet continues to be the king in the server side, but Bower is the new king of client-land.
Take a look in this post for more details and see a simple example:
http://nearsoft.com/blog/bower-and-asp-net-5-a-tutorial/
To answer the original question with a perspective from both enterprise and casual development...
History
Visual Studio has always been a standard development tool for efficiently building large-scale enterprise applications for Desktop, Mobile and Web. This included both client-side and server-side web applications built using Forms, MVC and the .NET Framework. Of course, what makes Visual Studio so appealing is the power behind it, which gives developers the ability to quickly generate, or scaffold, common solutions via project templates - allowing developers to focus on solving business problems.
For simple client-side web sites that use a few libraries and require minimal data interaction, a tool such as WebMatrix would often suffice due to being lightweight and able to serve up web sites with ease.
Many of those tools and technologies can be found at Microsoft /web.
Divergence
At the same time, there has existed a burgeoning Open Source community that has been developing many of the libraries and frameworks that have risen in popularity for building modern web sites and web applications.
For developers working with the "Microsoft Stack" of technologies, the gap was originally bridged by integrating NuGet into Visual Studio. Many, but not all, libraries and frameworks were available as NuGet packages; and there was plenty of support from Microsoft for working with these technologies. Microsoft had also created it's own open source mini-ecosystem called CodePlex to support development and sharing of projects, usually focused on their technology in some way.
Unfortunately, while the availability of technologies was fairly up to date for Microsoft developers, it had become more and more challenging to keep up because it wasn't just about the libraries and frameworks, but the workflow and the way these technologies were being made available, integrated and used.
Such workflows include:
client-side package management via Bower from Twitter
(Bootstrap, etc.)
node-based package management via NPM
client-side application scaffolding via Yeoman (e.g. generators for ASP.NET and knockout)
automated task running via Gulp and Grunt
pre-compiling CSS from either SASS or LESS
transpiling languages such as ES6 or TypeScript
testing (Jasmine, Karma, etc.)
bundling and deployment (Webpack, etc.)
Unfortunately, much of this is a manual process, such as identifying the right package for the job or writing different tasks that can eventually be run automatically. Each is truly a subject in and of itself! It's not uncommon to end up simply looking up a package or command for something that in the end could - and Visual Studio developers would say should - be automated.
Convergence
Microsoft has been slowly moving from not only supporting open source development but embracing it. It has made many of its core technologies available to the open source community via GitHub, as well as it's own .NET Foundation movement.
A major effort to converge by Microsoft was to introduce Visual Studio Code for multiple platforms - offering a simplified development experience that caters to the workflow that has become popular with the open source community.
Still, Visual Studio Code can be viewed as a major step back for developers used to much of the power and simplicity offered through Visual Studio through its automation of tasks and project templates. Microsoft introduced Web Essentials for 2010 and 2013 editions to keep up; but as many have observed, this was simply more of an effort to show support rather than a full integration into developer workflow.
Behind the scenes, Microsoft was looking to put it's .NET Framework on other platforms and established .NET Core. As of Visual Studio 2015 - specifically Update 3 and Node Tools - there is much deeper support for the open source development workflow with integration of NPM and Bower, as well as task running. These still require manual intervention but it's on par with the workflow outside of Visual Studio. It still feels foreign, but it's getting there.
The Future
With all that Microsoft has invested, it is clear that the next step is to bring together much of the steps taken to embrace open source development by providing a more visual and automated experience to Visual Studio Developers. This will include templates that generate rich web applications which not only have all of the necessary packages and dependencies defined, but the ability to bundle for distribution.
In the meantime, I think this is a great time for Visual Studio developers to get a feel for the current workflow, if just to appreciate how "the other guys" have been doing it. It won't be long before much of it will be simply a click away.
I'm thoroughly confused about how to properly deploy ASP.NET MVC with my application. As far as I understand, there are the following ways you can get it on a machine:
You can download a separate installer and install it on a machine that has the approprite .NET framework (although which MVC version requires which .NET framework?)
Some versions come along with .NET framework itself (though I can't find which version of MVC is shipped with which version of .NET);
Some versions are installed with Visual Studio (though again, no idea which versions are installed with which versions of VS). In this case, you can set Copy Locally to true for these references and perform a "bin deploy". You might need to add some extra references though (not sure which though).
You can also download MVC as a NuGet package, in which case it also downloads some other unrelated packages like WebPages, Infrastructure and Razor (which is my personal WTF - wasn't Razor a core part of MVC?). In this case the build process will automatically do a "bin deploy" by default (I think...)
So... WTF? What is the proper way to add MVC to your development workstation, what is the proper way to add the references to your project (NuGet? GAC?), and what is the proper way to deploy it to the target server (separate installer? .NET installer? bin deploy?)
"Proper" Development:
The "proper way" (by which I mean standard/redistributable way) would be using Nuget for your references. This means you can easily manage different versions and anybody else working on your project has a standard repository from which to pull the external requirements.
The NuGet documentation has a decent explanation of how to add references.
To install the appropriate version of MVC for developing through Visual Studio, just download and install it from the ASP.NET MVC website. This will install the necessary templates for you to create a new MVC project in Visual Studio. This will also include the necessary binaries, etc.
"Proper" Deployment:
Use bin deploy to deploy to your webserver. This means you don't need full admin priviledges to install the MVC requirements.
Phil Haack's guide will walk you through the process of bin deploying MVC3+
Keep in mind, the web server does need the appropriate .NET platform installed. You should install this via the appropriate redistributable installer if it is not already installed on the server.
Referring to the deployment i publish my asp.net app (i usually make web applications) to the file system in a directory (you can set also a server there, but i don't like it) and make an upload to the server with an FTP client of all the deployed folders. All the changes that i make to the app after (like bug correction) i deploy all the app again and upload single parts.
I hope i get your question in part, this is my first answer in SO.