Does anyone know how I can get the V3 version of ServiceStack.Client off Nuget? This wiki page appears to suggest that they should be there: https://github.com/ServiceStackV3/ServiceStackV3
I need to create a new project to interact with a legacy v3 ServiceStack implementation. I can't upgrade the existing API, but the JsonServiceClient in the new v4 is not compatible. I've imported the contracts DLL from our legacy API, which is causing the incompatibility issue.
The exact error is:
Error 105 The type 'ServiceStack.ServiceHost.IReturn' is defined in an assembly that is not referenced. You must add a reference to assembly 'ServiceStack.Interfaces, Version=3.9.48.0, Culture=neutral, PublicKeyToken=null'. D:\Projects\Adactus.Pulse\Main\Solutions\Integration\Mulesoft\SupplierIntegration\ScmtProcessor\InitialInstructionProcessor.cs 231 17 ScmtProcessor
Have they been moved by chance to a different nuget package name (i.e. the BSD version)? Or do I need to manually start copying DLL references around?
No they haven't been moved, you can see all the NuGet package versions listed on NuGet:
https://www.nuget.org/packages/ServiceStack/
https://www.nuget.org/packages/ServiceStack.Common/
You'll need to download the exact v3.9.48 packages you need, which the v3 page you linked to shows an example of:
https://github.com/ServiceStackV3/ServiceStackV3
Related
We use VS 2017 and consume NuGet packages the old way. We do not use PackageReference as of yet.
When a NuGet package reference is updated through the NuGet Manager in VS, the respective assembly binding redirect is not updated automatically - we have to do it manually.
So, I suppose it is up to the package to take care of it through the tools\install.ps1 script. Now, I think I know how to implement it, but I do not want to invent the wheel. Surely the code already exists somewhere, but where?
Clarification
Our application is strongly signed and it targets .NET 4.5.2 currently (soon to be upgraded to 4.7.2). We use packages.config.
I need to explain what is going on. There are three players on the field:
A tool - DbUpgrade
The tool plugin Api - DbUpgradeApi
An implementation of the plugin Api - LogDbUpgradeProgress
Let us inspect the DbUpgradeApi package. 3 versions of it are relevant to us:
The version against which LogDbUpgradeProgress is compiled - A
The version against which DbUpgrade is compiled - B
The latest version of DbUpgradeApi - C
The DbUpgrade tool loads the plugin LogDbUpgradeProgress at runtime. The binding redirects are needed, because A is not the same as B (and because the code is signed, nothing to do here currently)
If C is higher than B, then we should update the reference to DbUpgradeApi in DbUpgrade. But doing so must be accompanied with updating the binding redirect. And this is the essence of this question.
Ok, so I just spent the last hour testing, and I didn't need to do anything that I consider special for binding redirects to work.
But first, are you sure you need binding redirects? .NET Core doesn't need it. If you're using .NET Framework, but with a project using PackageReference, then it's resolved at build time, your app.config doesn't need the binding redirect in the version that's checked in with your code, but when you build and check the [your exe name].config file it does have the binding redirects. Also, binding redirects only matter when your assembly has strong naming. If you didn't sign your assembly, then binding redirect isn't needed.
Here are the steps that I took to create a reproduction of getting binding redirects in a console app using packages.config.
Create an empty folder to start with. I used dotnet new sln, dotnet net nugetconfig to generate a new sln and nuget.config file. I edited the nuget.config file to add the folder localFeed as a source, and set the globalPackagesFolder to gpf so I didn't pollute my real global packages folder with test packages. Also created a strong name key with sn -k snk.snk.
Create first test classlib. dotnet new classlib -n someLib. I edited Class1.cs to change the class name to SomeClass and added a property that retusns the value "Version 1". Used Visual Studio to set snk.snk as the signing key. dotnet pack to generate V1 of the package. I then edited SomeClass to change the message to "Version 2" and then ran dotnet pack /p:version=2.0.0. Finally, used nuget.exe add -source localFeed someLib\bin\Debug\someLib.1.0.0.nupkg and again for v2 of the nupkg.
Create the second test classlib, dotnet new classlib -n anotherLib and set the signing key to snk.snk. Changed Class1.cs to AnotherClass and added a property public string Message => new someLib.SomeClass().Message;. Added a reference to someLib version 1 in the csproj, then built, packed and used nuget.exe to add the nupkg to localFeed.
Opened Visual Studio and created a .NET Framework console app. Added a reference to anotherLib, which automatically brought in v1 of someLib. Upgraded the reference of someLib to v2, and confirmed that packages.config now has a binding redirect for someLib.
Created another .NET Framework console app and did the same as step 3, but this time using PackageReference instead of packages.config. The project app.config doesn't have binding redirects, but the .config file in the bin folder after build does.
edit: perhaps an important part to understanding NuGet/MSBuild binding redirect behaviour is the following: In both steps 3 and 4, if I add a reference only to anotherLib, then no binding redirect is created because all assembles that reference someLib reference the same version. Only by making my console app reference a different version of someLib than anotherLib uses, then the binding redirect is created.
In an app with plugins, the building the app assembly won't have a binding redirect, because it's the only assembly in the compile command line that uses the plugin contract dll, so no conflict to need a binding redirect. When the plugin assembly is built, only the plugin depends on the plugin contract dll, so again no conflict so no binding redirect. If you copy all the dlls into a single folder, then there can be a conflict in the required version, but this is a deployment time issue, not a build/compile time issue, so build tools may not help. One way to resolve this would be to add a reference to the plugin project from the app assembly. This way at compile time the build tools can see that two different versions of the plugin contract dll is used, so a binding redirect can be created. This only works if you build the app assembly. If the app is just a binary that you're given, then changing the binding redirects becomes a deployment time responsibility, so development/build tools may not help.
I recently started experimenting with dot net core , and one of my major problems was restoring the dependencies. I went into the the project.json file and added some dependencies , the name was correct but the version was just trial and error until i reached the recent version. I couldn't seem to find any documentation online either , can anyone help me find or show me where i can find a proper list of all the dot net core dependencies and their latest version ?
I have used core to great success. The package manager in VS2015 and 2017 does a great job of resolving both the version you are using and other available versions. If you are working directly with project.json ( not available in VS2017, dependencies have been moved back to the project file ), it will only tell you what packages are available via your user cache. ( found in C:\Users\YourUserNameHere.nuget\packages for both vs2015 and 2017 ) by typing the package name and then letting intellisense do it's thing.
Of course once you do a get of a package it is then available from your cache.
I've created a folder on my C:\packages. Inside I've created two packages with identical Ids but have different versions. I the use Nuget.Core to create a LocalPackageRepository pointing to this directory.
When I query for the packages using respository.FindPackages("myId")both packages are correctly returned by the service. However, the IsLatestVersion is true for both packages, even though their versions are clearly different.
Things I've tried:
I know these packages dicovered as OptimizedZipPackages looking through the source here, I cant find anything relevant to suggest an issue with the implementation.
I added the local repository to my Visual Studio NuGet feed manager. When I query that service, the latest version is shown.
Something seems to be wrong with how I've either created the packages, instantiated the repository, or its a bug in the library.
Using NuGet Core v2.8.60318.667
Looking at the source code the LocalPackage always returns true for IsLatestVersion if the NuGet package is not a pre-release.
In Visual Studio what happens is that the list of packages is further filtered by removing all but the latest version in the list so you only ever see the latest version. One way to do this is to use extension methods included in NuGet:
packages.DistinctLast<IPackage>(PackageEqualityComparer.Id);
The DistinctLast method assumes that the same NuGet package id will appear together in the list otherwise it will not filter them correctly.
I believe you could also use the AsCollapsed extension method which is similar to the above. It basically does:
packages.DistinctLast<IPackage>(PackageEqualityComparer.Id, PackageEqualityComparer.Version);
I am attempting to work through the N+1 TipCalc tutorial & get the following error when trying to compile the core project:
Error 1 Metadata file '1\packages\MvvmCross.HotTuna.CrossCore.3.0.4\lib\portable-win+net45+MonoAndroid16+MonoTouch40+sl40+wp71\Cirrious.CrossCore.dll' could not be found C:\Source.CS\trunk\Learning\Mono\TipCalc1\TipCalc.N=1\TipCalc.Core\CSC TipCalc.Core
Error 2 Metadata file '1\packages\MvvmCross.HotTuna.StarterPack.3.0.4\lib\portable-win+net45+MonoAndroid16+MonoTouch40+sl40+wp71\Cirrious.MvvmCross.dll' could not be found C:\Source.CS\trunk\Learning\Mono\TipCalc1\TipCalc.N=1\TipCalc.Core\CSC TipCalc.Core
Error 3 Metadata file '1\packages\MvvmCross.HotTuna.CrossCore.3.0.4\lib\portable-win+net45+MonoAndroid16+MonoTouch40+sl40+wp71\Cirrious.MvvmCross.Localization.dll' could not be found C:\Source.CS\trunk\Learning\Mono\TipCalc1\TipCalc.N=1\TipCalc.Core\CSC TipCalc.Core
NuGet 2.5 RC was installed from here https://nuget.codeplex.com/
Profile104 xml files created as per instructions & have been used for a few weeks with V3 prior to attempting to use NuGet for the MvvmCross components.
Pre NuGet TipCalc tutorial was accomplished without problems.
Downloading the complete project from GitHub also compiles without issues.
I haven't been able to see any difference between the packages.config file in the downloaded project and the project being created from scratch.
The profile of the core project is also the same in each case.
The dll's are at the location indicated.
There were no issues with using NuGet to download the package, only when attempting to compile the project.
Any suggestions as to what I have missed?
TIA
My guess is that the problem is in your path
The path seems to be C:\Source.CS\trunk\Learning\Mono\TipCalc1\TipCalc.N=1\TipCalc.Core\CSC
And the message is that '1\packages\MvvmCross.HotTuna.CrossCore.3.0.4\lib\portable-win+net45+MonoAndroid16+MonoTouch40+sl40+wp71\Cirrious.CrossCore.dll' could not be found
So maybe try using a path without an =?
How to build Autofac from sources? I found only one deprecated wiki page.
I've tried to launch go.cmd (.NET Framework 4.0), but it failed with errors:
C:\Autofac\Autofac.csproj" (default target) (4) ->
(CoreCompile target) ->
Builder\MetadataConfiguration.cs(28,14): error CS0234: The type or namespace name 'Linq' does not exist in the namespace 'System' (are you missing an assembly reference?)
[C:\Autofac\Core\Source\Autofac\Autofac.csproj] Features\LazyDependencies\LazyWithMetadataRegistrationSource.cs(28,14): error CS0234: The type or namespace name 'Linq' does not exist in the namespace 'System' (are you missing an assembly reference?)
What I am doing wrong?
Autofac 3.0 has been updated so the core Autofac.dll is a Portable Class Library that targets multiple platforms. Portable Class Libraries don't have references to System assemblies so the missing System.Core reference is correct - it shouldn't be there. You should be able to use the Portable Class Library with .NET 4... or with Windows Store or Windows Phone 8 apps. I strongly recommend not modifying the references for the .csproj. You'll break that compatibility and inadvertently change the target profiles.
The wiki page on building from source has been deprecated because the instructions for building are in a readme right in the root of the source code. (That's mentioned on that deprecated wiki page - first line.) It explains all the prerequisite tools and commands required. If you follow the information in there, you should not have to modify anything to get the source to build.
If you aren't modifying the sources, I'm not sure why you'd need to rebuild the source to target .NET 4 specifically. It should just work. If you see something that isn't working, please file an issue about it on the Autofac site.
If you are modifying the source, the readme in there should get you building without messing with the project references.
It looks like the Autofac.csproj does not include a reference to system.core. See also this question and this bugreport. So can you try to add this to the Autofac.csproj file:
<ItemGroup>
<Reference Include="System.Core" />
</ItemGroup>
Possibly you also have to add other references, such as System.