I have an extension package on our corporate nuget server for Asp.Net MVC 3 - let's say the package ID is currently Acme.Mvc and it's version is 2.x.
I've now branched that project and going to put a pre-release version of the same package targetted at MVC 4 Beta. Now, logically this is now version 3.x of the library; however, as soon as I release it (once it's no longer pre-release), the 2.x will no longer appear in VS' UI; which will potentially lead to other developers adding it to their MVC 3 projects; and deny them easy access to any future upgrades to the older v2.x library without using the console).
In a couple of other cases, I've changed the package id to include a version i.e. Acme.Mvc.3 so the new and old can sit side by side. Only problem with that is that it's then possible for someone to try and include both! There's also the slightly pedantic issue that to call that v3.x is not necessarily correct; because it's a new package.
Also, I really need to be able to maintain both streams. I can rely on Binding Redirects in MVC 4 sites that still reference the version of the library that targets MVC 3; since none of my extensions rely on stuff that's gone.
When I look at the public nuget feeds; I rarely ever see this practise of sticking a major version in the package ID, but is there really any alternative?
There are many existing packages that uses the MVC version as part of their naming convention to differentiate between supported versions :
WindowsAzure.WebRole.MVC3
Unity.Mvc3
Spark.Web.Mvc2
Spark.Web.Mvc3
...
"Only problem with that is that it's then possible for someone to try and include both!"
I wouldn't bother trying to block this case, it would seem obvious by the name of the package that both are not meant to be side-by-side.
Related
I have an question regarding updates to the framework of a Laravel application.
Normally I run the composer update command to update all of its dependencies. For the laravel framework the package laravel/framework is used.
But they made some changes in this package which require you to make changes in the core application (not in composer). The core application is the package laravel/laravel.
For example, in this commit they have made a function called confirmPassword() which refers to a file ConfirmPasswordController.php in the package laravel/laravel.
But this file didn't exists on my application because my application is not up-to-date.
My question
How do i keep my core application up to date?
Errors
See a typical example of updating the dependencies but not the application here.
First of all... This is not an easy question and IMO there are MANY possible scenarios... Depending on the code you developed, the packages you're using, the version you want to use, and so on...
Anyway This is what I would do in this situation:
Let's say for example I want to upgrade from version X to version Z where Z is two major / minor releases ahead of X
Step 1
Follow the next steps for one major / minor realease at time. Once I've tried to upgrade an application from Laravel 5.4 to 5.6 and it was completely broken. So I decided to upgrade to 5.5 and test the everything was working and, in case, block at that release. Luckily when I've upgraded from 5.5 to 5.6 (after code fix) I've managed to make everything work as it should.
Step 2
Upgrade the core framework and the plugins, check for errors during the upgrade and ofc, check the official documentation for any kind of compatibility problem
Step 3
Laravel has it's own upgrade guide that should be followed step by step. A good chunk of errors can be solved simply following that guide. There may be some plugins that doesn't provide it but usually the problems are releated to new features... It's hard that a method, class or trait has completely changed from one version to another.
Step 4
This step can be omitted, but from the example you've provided maybe it's better to add it. When there is a new feature that requires a specific class or trait or whatsoever, the simplest way to check if the error is thrown because of a file missing (and that is part of the "boilerplate") or has a different nature, is to create an empty project with that specific version and make a comparison with the "default" files.
For example, if you made no changes to the LoginController, checking if the new version has any kind of updates, may be the solution.
You can do this manually, following the upgrade guide for the version you're upgrading from/to, for example this one.
Alternatively, Laravel Shift is a paid but fairly inexpensive tool that will do it for you automatically. Since it's making changes to your project, you should carefully review everything it's done.
I made a Laravel app as a side project and the final version was 2.6.4
I choosed to rewrite it completely and rename.
I changed blade templating to Vue.js, made a better Model and Controller structure, etc.
Should the new version be 1.0 or 3.0
You should make it 3.0
As it is the same project you've been working on and made improvements in.
As maybe your question or confusion is arising from the fact that you've made a complete re-write. But with projects, it usually happens. A complete re-write is usually marked with a version bump.
If the project, however, changes and caters something else than you begin with.
That project would be named differently and have 1.0 as the version.
Am trying to install SIGNALR to my asp.net project, but when adding the Nugets, it keeps pushing an error that the "Package xxx was restored using .NETFramework, Version=v4.6.1 instead of the project framework .NETCoreApp, Version=v2.0". I get this error on several Nugets. I tried to re-install all Nuget one by one but same result when I arrive at some particular one like SIGNALR.
I believe I might have something wrong in the setup, but as am new to asp.net, would love a pointer. Read the literature but could not find the answer to this issue.
It also looks like SignalR might only be available for netcore 2.1 later this year but am looking for a way to use it, in a simple app.
So a couple of things.
For the latest SignalR Core bits you need to be targeting netcoreapp2.1. Preview1 and later depend on that.
If you want to just experiment with SignalR targeting netcoreapp2.0 the alpha 2 bits use netcoreapp2.0. But just to be clear the alpha bits are just a public preview and should not be used for production applications.
The main thing here though is that you are using the Microsoft.AspNet.SignalR packages. Those will not work on Core.
I've seen examples that that indicate IApplicationBuilder has an extension method .UseJwtBearerAuthentication(Action<?> options).
This SO question and AspNet.Security.OpenIdConnect.Server
sample server startup file seem to say that there is such an extension. On the OpenIdConnect, I looked at the extensions folder and I don't see an extension named UseJwtBearerAuthentication. Even this blog says that it's supposed to be included with ASP.net 5. I also tried adding Microsoft.AspNet.Security.OAuthBearer, 1.0.0-beta3 to my project.json and reference it in Startup.cs. No help.
The only thing I have different is that I'm using -beta7, but I don't think that should matter.
It depends on your runtime version. In beta7 the package is called Microsoft.AspNet.Authentication.OAuthBearer, while in beta 8 the package is renamed to Microsoft.AspNet.Authentication.JwtBearer.
Since you are using beta7, add this to your project.json:
"Microsoft.AspNet.Authentication.OAuthBearer": "1.0.0-beta7"
Pro-tip: never mix beta versions like beta3 security packages and beta7 MVC packages.
In RC2, there are
Microsoft.AspNetCore.Authentication.JwtBearer
Microsoft.AspNetCore.Authentication.OAuth
I'm not sure if this problem is connected specifically with log4net or this is some problem with VS.
Everytime I'm trying, I have the same result. But let's start from the beginning.
I'm creating a simply console application (.net 4) and using nuget to install the log4net library.
Now, when I want to add some code from it, intellisense works ok:
But when I try to compile it, I have an error
This is the only one assembly I found to this moment, I have this problem with. I have absolutly no idea what (and why) is going on. I have checked with two other solutions and problem is the same. I have not checked manually downloaded version yet.
Most likely there is an underlying dependency that is missing. One very common reason is the project is using the Client Profile instead of the full .NET 4.0. (Not sure about log4Net, but I run into this a lot when including third party libraries, esp. those with ties to the web). If I am correct, simply going into properties and changing the framework version to full .NET 4.0 will solve the issue.