How can I convert this project into .NET Core?
I tried (according to this site) to change the file ActiveDirectoryAuthentication.csproj as follows:
<PropertyGroup>
<TargetFramework>netcoreapp2.2</TargetFramework>
</PropertyGroup>
but when I open the file in Visual Studio 2019 it looks like this:
It's probably easier to start fresh. You are following a tutorial that is talking about an existing database/project.
Instead start here : https://learn.microsoft.com/en-us/ef/core/get-started/aspnetcore/new-db?tabs=visual-studio which is the same tutorial but actually starts fresh.
At a guess, If you are using Visual Studio, you need to install the .NET Core workloads and/or install the .NET Core 2.2 SDK https://dotnet.microsoft.com/download/dotnet-core/2.2
As well as updating the target framework you're using, you also need to make sure that all of your dependencies work with .NET core too, and in cases where they don't you'll need to find alternative packages that do.
https://learn.microsoft.com/en-us/dotnet/core/porting/ offers a wonderful guide on porting to .NET core, and also offers a number of CLI tools for checking how easy it will be to port your code.
Hope that helps,
Alex
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 have developed a commercial extension for the Unity3D game engine in F#, it's a piece of code which extends the editor with advanced node/graph editing features. F# is perfect for this due to the nature of immutability and DU's.
But, to my question: I realized that the license for the FSharp.Core.dll which comes with Microsoft .NET/Visual Studio probably doesn't allow you to re-distribute it with a commercial project? How would I go about finding out if this is the case or not, and if it's not is there any way to create my own compiled version of FSharp.Core.dll which would run on Unity3D?
The reason I ask is because Unity3D uses Mono 2.6 (albeit a modified version, to my understanding) under the hood, and there is no FSharp.Core.dll bundled with the editor, so I need to supply my own with my extension.
See: Is F# 3.0 runtime redistributable?
The answer is of course Yes. The language would be pretty useless if its core library wasn't re-distributable...
Related to: Package an ASP.NET MVC application with Nuget
I'm trying to get a mode where I can edit an MVC project and package it easily.
As often suggested it is wise to replace a namespace using NuGet pre-processor functionality.
This would mean that I would have to edit my source files and add the pp extensions to each pre-processed source file.
Are there any tips and tricks to make this less labourious?
There is such a tool, that did almost exactly what I wanted. It's on Codeplex so I could participate in the development, yay!
https://nugetpackager.codeplex.com/
It has a common-line interface too, so I can script my updates.
I am working on an open source project MvcSiteMapProvider getting it ready for deployment. It is a library package that supports MVC2, MVC3, and MVC4 as well as .NET 3.5, .NET 4.0, and .NET 4.5.
Based on Nuget Package: Use Different MVC Version When Available, I have come to the conclusion that I need to make a Nuget package for each version of MVC and let Nuget's internal version detection take care of the different .NET versions, like this:
MvcSiteMapProvider.MVC2
MvcSiteMapProvider.MVC3
MvcSiteMapProvider.MVC4
However, in addition to a library DLL, I have different files (Dependency Injection configuation, MVC DisplayTemplates, etc.) that need to be deployed to the target project. These files MUST NOT be updated when the new version of the main project is updated because they will likely contain end-developer edits that I don't want to overwrite.
So, it is clear that these need to be in their own Nuget packages for this and other reasons. However, these other packages need to depend on the main MvcSiteMapProvider.MVCx projects, just to ensure one of them has been installed.
It doesn't make sense to make a separate Nuget package for each version of MVC for each of these other packages - they are all exactly the same except for this one dependency. Ideally what I would like to do is make a single Nuget package that depends on either MvcSiteMapProvider.MVC2, MvcSiteMapProvider.MVC3, or MvcSiteMapProvider.MVC4 and if none of them are available, install the one that matches the MVC version of the target project, but how would I accomplish this? If that is not possible, what other options do I have than creating large number of Nuget packages (one for each MVC version dependency) that grows exponentially with each new MVC release?
To clarify, I have other Nuget packages like this:
MvcSiteMapProvider.Web
MvcSiteMapProvider.Configuration.Autofac
MvcSiteMapProvider.Configuration.Ninject
MvcSiteMapProvider.Configuration.StructureMap
MvcSiteMapProvider.Configuration.Unity
MvcSiteMapProvider.Configuration.Windsor
I am trying to avoid having to change that to:
MvcSiteMapProvider.MVC2.Web
MvcSiteMapProvider.MVC2.Configuration.Autofac
MvcSiteMapProvider.MVC2.Configuration.Ninject
MvcSiteMapProvider.MVC2.Configuration.StructureMap
MvcSiteMapProvider.MVC2.Configuration.Unity
MvcSiteMapProvider.MVC2.Configuration.Windsor
MvcSiteMapProvider.MVC3.Web
MvcSiteMapProvider.MVC3.Configuration.Autofac
MvcSiteMapProvider.MVC3.Configuration.Ninject
MvcSiteMapProvider.MVC3.Configuration.StructureMap
MvcSiteMapProvider.MVC3.Configuration.Unity
MvcSiteMapProvider.MVC3.Configuration.Windsor
MvcSiteMapProvider.MVC4.Web
MvcSiteMapProvider.MVC4.Configuration.Autofac
MvcSiteMapProvider.MVC4.Configuration.Ninject
MvcSiteMapProvider.MVC4.Configuration.StructureMap
MvcSiteMapProvider.MVC4.Configuration.Unity
MvcSiteMapProvider.MVC4.Configuration.Windsor
Looking at your source code, it seems like you are referencing multiple versions of the Microsoft.AspNet.Mvc package in MvcSiteMapProvider project. I am not sure this is working as you expect it to since there can be only one version of System.Web.Mvc that can be put in the bin folder during the compilation process (the latest version 5.0.0 will be used).
So any code in your package that depends on Mvc V3 or V4 is not really getting the dll it expects.
Since most of the packages you referenced above like Autofac also have integration package that target specific MVC versions,you may not have an option but to split your package into smaller packages like you mentioned in your post.
A better approach to this problem would be to separate the Core functionality provided by your package which does not have dependency on any version of MVC. You can then create different wrapper packages that depend on your core package and also on a specific version of Microsoft.AspNet.Mvc. And create similar packages for each different Configuration has a nuget dependency on third party packages like Autofac (eg Autofac.Mvc5) and its corresponding version of your MvcSiteMapProvider.MvcX package