I need to create a mechanism to request the latest version of my API. I know that you can specify a default version, but I don't need this. The purpose is to access to https://<server>:<port>/api/latest/<controller>, where latest is actually the most recent version. I need to define both versioning options: the major/minor and this one. Below are the two different ways to perform requests:
https://<server>:<port>/api/latest/<controller>
https://<server>:<port>/api/v1/<controller>
https://<server>:<port>/api/v1/<controller>
In the above example, the latest would point to the v2.
The difficulty here is that the built-in ApiVersioning from ASP.Net Core (the Microsoft.AspNetCore.Mvc package) doesn't support string named versions since the ApiVersion uses integers for versioning.
Is there any "clean way" to achieve it?
We have recently upgraded our API's (using Forms Authentication) Servicestack version 4.0.40 to latest stable version of Servicestack (V5.1.0). We use Autofac Ioc registration using InstancePerHttpRequest for API's (this is using Autofac.Integration.Mvc from Autofac.Mvc4 package).
Below code does not work anymore after servicestack upgrade.
this.UseAutofac(afcBuilder.Build());
Error CS0012 The type 'ServiceStackHost' is defined in an assembly
that is not referenced. You must add a reference to assembly
'ServiceStack, Version=4.0.48.0, Culture=neutral,
PublicKeyToken=null'.
So we have tried alternate ways to make it work using InstancePerDependency but that is causing missing "ASP.NET_SessionId" cookie value after API authentication.
Please suggest code to get actual "InstancePerHttpRequest" work with latest ServiceStack version.
I've already answered this question in ServiceStack Customer Forums but for anyone else's benefit with similar issues I'll include it below:
The issue isn't with ServiceStack or AutoFac it's with one of your dependencies which still has a binary reference to an old v4.0.48 of ServiceStack (highlighted in the Exception). You can't mix and match ServiceStack .dlls from different versions so you would need to re-compile whichever assembly has the old binary ServiceStack reference to use the version of ServiceStack you're using.
Autofac wouldn't have a dependency to ServiceStack, it would be one of your dependencies that is registered with Autofac. You can either use an Assembly inspector like JetBrains dotpeek and inspect the .dll references of each dll reference in your project or comment out registrations until you find the one with the dependency.
Basically you're unlikely to get anywhere focusing on ServiceStack or Autofac .dll's, you need to find the .dll that has a reference to ServiceStack v4.0.48 and re-compile it to use the version of ServiceStack you've upgraded to.
If you look at the dependency of Autofac.Mvc4, you'll see it only has a dependency to Autofac. Autofac's not going to have a dependency to ServiceStack v4.0.48, one of your own .dll's is going to have the old binary reference that's causing the issue.
Suppose I have a class library which I want to target netstandard1.3, but also use BigInteger. Here's a trivial example - the sole source file is Adder.cs:
using System;
using System.Numerics;
namespace Calculator
{
public class Adder
{
public static BigInteger Add(int x, int y)
=> new BigInteger(x) + new BigInteger(y);
}
}
Back in the world of project.json, I would target netstandard1.3 in the frameworks section, and have an explicit dependency on System.Runtime.Numerics, e.g. version 4.0.1. The nuget package I create will list just that dependency.
In the brave new world of csproj-based dotnet tooling (I'm using v1.0.1 of the command-line tools) there's an implicit metapackage package reference to NETStandard.Library 1.6.1 when targeting netstandard1.3. This means that my project file is really small, because it doesn't need the explicit dependency:
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFramework>netstandard1.3</TargetFramework>
</PropertyGroup>
</Project>
... but the nuget package produced has a dependency on NETStandard.Library, which suggests that in order to use my small library, you need everything there.
It turns out I can disable that functionality using DisableImplicitFrameworkReferences, then add in the dependency manually again:
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFramework>netstandard1.3</TargetFramework>
<DisableImplicitFrameworkReferences>true</DisableImplicitFrameworkReferences>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="System.Runtime.Numerics" Version="4.0.1" />
</ItemGroup>
</Project>
Now my NuGet package says exactly what it depends on. Intuitively, this feels like a "leaner" package.
So what's the exact difference for a consumer of my library? If someone tries to use it in a UWP application, does the second, "trimmed" form of dependencies mean that the resulting application will be smaller?
By not documenting DisableImplicitFrameworkReferences clearly (as far as I've seen; I read about it in an issue) and by making the implicit dependency the default when creating a project, Microsoft are encouraging users to just depend on the metapackage - but how can I be sure that doesn't have disadvantages when I'm producing a class library package?
In the past, we've given developers the recommendation to not reference the meta
package (NETStandard.Library) from NuGet packages but instead reference
individual packages, like System.Runtime and System.Collections. The
rationale was that we thought of the meta package as a shorthand for a bunch of
packages that were the actual atomic building blocks of the .NET platform. The
assumption was: we might end up creating another .NET platform that only
supports some of these atomic blocks but not all of them. Hence, the fewer packages you reference, the more portable you'd be. There were also concerns regarding how our tooling deals with large package graphs.
Moving forward, we'll simplify this:
.NET Standard is an atomic building block. In other words, new platforms
aren't allowed to subset .NET Standard -- they have to implement all of it.
We're moving away from using packages to describe our platforms,
including .NET Standard.
This means, you'll not have to reference any NuGet packages for .NET Standard
anymore. You expressed your dependency with the lib folder, which is exactly how
it has worked for all other .NET platforms, in particular .NET Framework.
However, right now our tooling will still burn in the reference to
NETStandard.Library. There is no harm in that either, it will just become
redundant moving forward.
I'll update the FAQ on the .NET Standard repo to include this question.
Update: This question is now part of the FAQ.
The team used to recommend figuring out what the slimmest package set was. They no longer do this, and recommend people just bring in NETStandard.Library instead (in the case of an SDK-style project, this will be done automatically for you).
I've never gotten a totally straight forward answer as to why that was, so allow me to make some educated guesses.
The primary reason is likely to be that it allows them to hide the differences in versions of the dependent libraries that you would otherwise be required to track yourself when changing target frameworks. It's also a much more user friendly system with the SDK-based project files, because you frankly don't need any references to get a decent chunk of the platform (just like you used to with the default references in Desktop-land, especially mscorlib).
By pushing the meta-definition of what it means to be a netstandard library, or a netcoreapp application into the appropriate NuGet package, they don't have to build any special knowledge into the definition of those things as Visual Studio (or dotnet new) sees them.
Static analysis could be used during publishing to limit the shipped DLLs, which is something they do today when doing native compilation for UWP (albeit with some caveats). They don't do that today for .NET Core, but I presume it's an optimization they've considered (as well as supporting native code).
There's nothing stopping you from being very selective, if you so choose. I believe you'll find that you're nearly the only one doing it, which also defeats the purpose (since it'll be assumed everybody is bringing in NETStandard.Library or Microsoft.NETCore.App).
You shouldn't need to disable the implicit reference. All platforms that the library will be able to run on will already have the assemblies that the NETStandard.Library dependency would require.
The .NET Standard Library is a specification, a set of reference assemblies that you compile against that provides a set of APIs that are guaranteed to exist on a know set of platforms and versions of platforms, such as .NET Core or the .NET Framework. It is not an implementation of these assemblies, just enough of the API shape to allow the compiler to successfully build your code.
The implementation for these APIs are provided by a target platform, such as .NET Core, Mono or .NET Framework. They ship with the platform, because they are an essential part of the platform. So there is no need to specify a smaller dependency set - everything's already there, you won't change that.
The NETStandard.Library package provides these reference assemblies. One point of confusion is the version number - the package is version 1.6.1, but this does not mean ".NET Standard 1.6". It's just the version of the package.
The version of the .NET Standard you're targeting comes from the target framework you specify in your project.
If you're creating a library and want it to run on .NET Standard 1.3, you'd reference the NETStandard.Library package, currently at version 1.6.1. But more importantly, your project file would target netstandard1.3.
The NETStandard.Library package will give you a different set of reference assemblies depending on your target framework moniker (I'm simplifying for brevity, but think lib\netstandard1.0, lib\netstandard1.1 and dependency groups). So if your project targets netstandard1.3, you'll get the 1.3 reference assemblies. If you target netstandard1.6, you'll get the 1.6 reference assemblies.
If you're creating an application, you can't target the .NET Standard. It doesn't make sense - you can't run on a specification. Instead, you target concrete platforms, such as net452 or netcoreapp1.1. NuGet knows the mapping between these platforms and the netstandard target framework monikers, so knows which lib\netstandardX.X folders are compatible with your target platform. It also knows that the dependencies of NETStandard.Library are satisfied by the target platform, so won't pull in any other assemblies.
Similarly, when creating a standalone .NET Core app, the .NET Standard implementation assemblies are copied with your app. The reference to NETStandard.Library does not bring in any other new apps.
Note that dotnet publish will create a standalone application, but it won't doesn't currently do trimming, and will publish all assemblies. This will be handled automatically by tooling, so again, trimming dependencies in your library won't help here.
The only place I can imagine where it might help to remove the NETStandard.Library reference is if you are targeting a platform that doesn't support the .NET Standard, and you can find a package from the .NET Standard where all of the transitive dependencies can run on your target platform. I suspect there aren't many packages that would fit that bill.
I have a REST API that was working with Jersey 2.6 and Swagger 1.3.7. I read that Jersey 2.9 fixes a warning that I was getting so I upgraded to the latest Jersey 2.16 but then Swagger stopped working. I went back and upgraded one version at a time until I saw that Swagger was working with 2.15 so I settled on that. Now, the PUT API fails with Swagger with the following error:
The server refused this request because the request entity is in a format not supported by the requested resource for the requested method
The API works using FireFox RESTClient and specifying "application/json".
I do have "jersey-media-json-jackson" as a dependency and call "Client client = ClientBuilder.newClient().register(JacksonFeature.class);" in the program.
I tried upgrading Swagger but that did not help.
Has Swagger been verified to work with Jersey 2.15/2.16?
I've recently managed to get swagger-core to work with Jersey 2.16 with a similar issue. Keep in mind they are using the latest version (1.5.X) and not 1.3.X but the same solution will apply.
The problem is most likely with version resolution, specifically, the one of jackson-databind. For some reason, even jersey-media-json-jackson 2.16 depends on an older version of jackson-databind, even though it works fine with the latest version. Without having more details, it would be difficult to suggest a full solution, but you can follow the dependency tree and see the conflicts there.
If you do require further assistance, I'd suggest either using our mailing list, or even better, the IRC channel where we could interact online and resolve it.
Is there anyway i can check if .NET 2.0 is installed without any errors?
The answer here led me seriously astray... i found microsoft's own documentation: .NET Framework 2.0 Redistributable Package Reference: Detecting Installed .NET Framework 2.0
This documentation states:
The Setup.exe bootstrapper should use the following registry key to detect the .NET Framework version 2.0.
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\NET Framework Setup\NDP\v2.0.50727
It then verifies the existence of the entry value:
Install (DWORD value = 1)
Note The same registry key will be checked for all versions of Dotnetfx.exe regardless of language. Therefore, if you want to display dialogs in a specific language you should use the corresponding version of Dotnetfx.exe. You do not need to make any changes to the settings.ini file when deciding which version of Dotnetfx.exe to use.
works like a charm... i realize this question and answer is 2 years old or more... but i got here from a search engine, and this is here for the next person who does the same... hope this helps -ck
This blog post describes two options for checking for a .NET installation, as well as retrieving versioning information.
The second option (using CorBindToRuntime) will fail if the .NET installation cannot be loaded. This might help you determine if there are any errors in the install - or at least whether the framework loads properly.
If you're using ClickOnce as your publishing method, you can click on the "Prerequisites" button in the "Publish" tab of the project's properties and check the box for ".Net Framework 2.0". This will make sure that framework is installed before the program installs, and can fetch and install the framework if necessary, too.
In regular VS Setup Projects, right-click on the setup project, chose View->Launch Conditions and add it as a condition. Visual Studio should have added one for you that matches the target platform of the project.