I'm familiar with the new deployment/installation design of VS 2017, and the way it leaves no footprint on registry.
And I'm also familiar with how we need to change our check-in policy installation from registry manipulation to VS extension creation.
However, now I need to create check-in policies in .NET Core 2.0. The problem is that I need to use Microsoft.TeamFoundation.VersionControl.Client dll to be able to access PolicyBase and also PendingChange classes. This results in FileNotFoundException.
Also I need to use Mono.Cecil as the reflection library, to be able to process things in more detail before checking-in. I can't find if Mono.Cecil supports .NET Core 2.0 or not. Nuget page is not informative and the libraries page on GitHub is also not easy to understand.
And another obstacle is to create a VS Extension. I can't find out the required package definition items to be added to source control.
Can you please provide a simple example of how to create a custom TFS Check-in Policy in VS 2017 via .NET Core 2.0?
Since the policy ends up running in the context of Visual Studio itself, I believe you have to be compatible with the .NET framework that Visual Studio is running in, and that is the "classic" .NET Framework, not .NET Core. Libraries written to a .NET Standard can potentially be consumed by both .NET Framework and .NET Core applications, and I believe you could also include separate executables in an extension and run them as separate processes if there's some piece that absolutely must run in a .NET Core environment, but you can't mix-and-match within a single process, and the extension code itself doesn't get a choice: it runs in the Visual Studio process.
Related
I have visual studio 2015 professional editton, and i want to create my first MVC web application which should be a .net core. now i am watching an online learning demo, which mentioned to create this project:-
while inside my visual studio i have these options:-
so which option i need to chose?
second question, how i can be sure that i am using the latest version of MVC?
Thanks
First, there is no such thing as MVC 6. It's ASP.NET Core. Second, the decision of whether to use .NET Core or .NET Framework comes down to what you need to do. .NET Core is cross-platform (Windows, Mac and Linux), whereas .NET Framework is Windows-only. .NET Core is also lighter weight, faster, and has a number of new CLR features, compared to .NET Framework. Virtually the only reason to use .NET Framework is if you have a dependency on something that utilizes Windows-specific APIs, meaning it can't be run cross-platform. Otherwise, you should always use .NET Core, if you can get away with it.
ASP.NET Core is really just a collection of NuGet packages, and like other NuGet packages, they can be updated easily. However, the difference is that these NuGet packages are generally tied to a particular version of .NET Core, and thus, the appropriate version of the packages are installed based on which version of .NET Core you're targeting. For example, if you're targeting netcoreapp2.2 then you'll see that that packages like Microsoft.AspNetCore.App will be brought in with versions like 2.2.x.
So, to answer your question about staying up to date, it essentially entails installing the latest version of the .NET Core SDK, and then changing your project to target that new version. Then, all the ASP.NET Core NuGet packages will naturally update accordingly.
This issue is exactly as described in the title.
I have a portable F# class library. I have created an ASP.NET Core Web Application (both .NET Framework and .NET Core), from which I have tried to add a reference to my F# class library.
Trying to add the reference gives a message:
The following projects are not supported as references:
Project type is unsupported by current project and can not (sic) be referenced.
This is extremely disappointing, as the .NET Core is now in General Availability.
Are there any workarounds while this bug gets addressed?
I have a project, which I started with Beta8 bits of .net core and since then I have an F# library, which I use from an asp.net core C# app. (btw here is an RC2 based minimal sample for referencing the F# lib from a net core based console app)
Here is how I did it:
Currently (according to my knowledge) there is no template in VS to create a coreCLR based F# library (the PLC templates under F# are all Full framework based, but that you still cannot reference from asp.net core even if it runs on full framework), so you have to do this with the command line. This is done by:
dotnet new --lang F#
This creates you a hello world coreCLR F# app. You can turn the app into a class library by modifying project.json file.
If you have a VS solution and you click to “Add” -> “Existing project” you can select the project.json file. This way you add it to your solution (and btw. an xproj file will be also created).
So at this point you will have the coreCLR based F# project in your solution. I believe by right clicking the asp.net core project and go to “Add” -> “Reference” -> Projects->Solutions and selecting the F# library you can already reference it. If this does not work, you can do it manually: just list the F# project under the “dependencies” in the project.json of the asp.net core application.
If your asp.net core app runs on full framework still need to do these steps. It actually doesn't really matter.
Now the bad part:
In the RTM (released on Monday) the “dotnet new” command creates an uncompliable F# app, because of some dependency issues. This is tracked here (the title says "on macOS", but it's the same on Windows) and as soon as it’s solved this should be fine (or if you did not yet install RTM and you have RC2 you are also good).
Intellisense and debugging across F# and C# does not work (I posted it here)
Although .NET Core has officially been released, the vast majority of the nuget packages in the ASP.NET Core Web Application are in prerelease. Moreover, although the entity framework identity model has been cleaned up, my attempt to change the key columns for users and roles from strings to ints generated an obscure error when I tried to implement Entity Framework migrations. I know I can do it for a .NET Web Application, even though the process is clunky in places. So for now I have gone back to using a .NET Framework Web Application. I'm looking forward to seeing a fully mature version of ASP.NET Core Web Applications. It's not ready, but it looks very promising.
I have a MVC 2 project created in Visual Studio 2010 that use MvcSiteMapProvider.dll and works fine. But when loading the project in Visual Studio 2013, everything else work fine except it crashes at
Html.MvcSiteMap().SiteMapPath
The error message is
An exception of type 'MvcSiteMapProvider.MvcSiteMapException' occurred in MvcSiteMapProvider.dll but was not handled in user code
I believe that MvcSiteMapProvider.dll cannot be loaded correctly. I need help on this. Thanks.
Note that there is a separate DLL for each .NET framework version, and I suspect you are targeting the wrong framework. This can happen if you install MvcSiteMapProvider into your project and then change it to a different .NET framework version.
NuGet does not automatically upgrade/downgrade packages to the currently set framework version. This step must be done manually. The best way is to completely uninstall and reinstall the package as per this document. Also be sure to read this before attempting it.
But do note that if you do this NuGet will not remove any files you have changed (like Mvc.sitemap) and then prompt you whether to overwrite them. You should normally say no to each prompt to ensure your custom configuration is not overwritten.
Also note that it is not sufficient to use Assembly Binding Redirection with MvcSiteMapProvider because with each .NET framework version we create a separate build (DLL) that takes advantage of features that are not present in prior versions.
I've been exploring the Azure Active Directory services and was pleased with how easy it was to hook up an arbitrary ASP.NET MVC website to it. I've experimented with this in Visual Studio 2012 and all works well. Especially using the Identity and Access Tool extension for VS2012.
Now here comes the tricky part: This tool is however deprecated and not supported on, nor available for Visual Studio 2013.
There are several MSDN documents on the matter, like this excellent tutorial, only I find them all targeting VS2012 and the forementioned tool. For new projects the process is "simplified when creating a new web application". But I don't want a new application - I want to hook up existing applications in VS2013.
Now the question is: is there a 'decent' way to integrate Azure ActiveDirectory, especially the Single Sign-On feature, to an existing ASP.NET MVC 5 web application in Visual Studio 2013?
At least with the same ease as the I&A Tool, but without the need to recreate or migrate my entire application, of course.
Depending on the complexity of your project, you can either create a new project and import your project files to the new project or import the identity settings to your existing project.
Since the identity controls are really just a set of files and configuration, you should be able to create a project with the identity settings you want and then copy over the files / configuration to your existing project. You may also need to add references to things like Microsoft.AspNet.Identity.Owin and any security providers you need. Files to take a look at include:
App_Start/IdentityConfig.cs
App_Start/Startup.Auth.cs
Controllers/AccountController.cs
Startup.cs
Web.config
Yes, it's a pain, and hopefully there will be an easier way of adding or changing identity later, but this is the best I've come up with for now.
We are in the middle of development for a core ASP.NET MVC web project and a customer plugin in the form of an MvcContrib plugin web project -- a web project injected into the core web as an area. The plugin is a soft reference in the core project, so it can be developed completely separately and dropped in.
I am trying to generate a way to debug/code the plugin, so that the multiple custom plugins can be developed independent of the core web.
The developers should only have to worry about coding and testing the plugin code. Also, I don't want them to change the core code in this custom plugin project -- that should be done in the core anyway.
I created the core web as a NuGet package and included all the necessary files so I could include it in a web.
My thinking was that I could create an empty web, install my core web, and the developers could have an F5-driven debugging environment.
I tested by creating a blank Mvc project, installed my core package and included one of my plugins. I changed the namespace of this empty web app to the namespace of the core web, thinking that Visual Studio debugging would properly attach and my core assembly.
Simple VS debugging in the empty app does not work -- I receive an HTTP Exception, most likely due to my routes not being registered. I also see that my log4net is not creating its logs folder, so I know the assembly's app start is not being called.
So I see that VS is not attaching to and calling my core assembly.
Can I use this empty web as a host project for my nuget installed web and debug? If so, what configuration am I missing?
If not, how can I include the core web in each customer plugin project in such a way that I can drop my DLL into the bin and debug it?
Using:
Visual Studio 2010
ASP.NET MVC2
The way we are doing things that works pretty well is to use a combination of Web Activator and Razor Generator (available as a Visual Studio extension). In order to access the views within the core web application, the consuming client application needs to know about them, either because they are all included as file references inside the Nuget package (messy) or because they are compiled into the core web dll. You can do that using Razor Generator. Once installed via Nuget you would need to change the Custom Tool property for each .cshtml file to RazorGenerator, which will create a .generated.cs file for each view. This will allow your sample client to use the layout and views from the core web application.
David Ebbo has some useful blog posts on Razor Generator
Couple that with Web Activator to create a PostActivationStartMethod that runs your initialisation code (such as initialising Log4Net) and you should be good to go. We've had this running in 2 scenarios - consuming the framework package via Nuget and adding a project reference directly. Debugging was not working for the Nuget package consuming route but we don't include the pdb files in the Nuget package. We can debug when adding a project reference directly though.