I am trying to integrate Structure map as a DI container with my mass Transit code.
It seems there is a conflict in the Nuget Packet versions .
The assembly MassTransit.StructureMapIntegration expects a signed
version 3.1.6.191 of structuremap. But the corrosponding unsigned
package for structure map has the latest version of 3.1.6.186.
This results in mismatch between the code.
I tried to downgrade the signed structure map assembly to 3.1.6.186 to make sure it is the same as the unsigned version of structure map, but this seems to create issues with the MassTransit Structure map Nuget package. The Mass Transit Structure Map Nuget package does not have any versions which accepts 3.1.6.186 signed structur map assembly version .
How do I get around this conflict ?
Is there another location which I can use to get MassTransit Structure Map nuget package which supports 3.1.6.186 ?
As mentioned by Chris ( one of the maintainers of Mass Transit ) in the comment , Mass Transit 3.2.0 now has support for unsigned Structuremap assemble which resolves this issue.
Related
I have a Golang service which uses Protobuf. The library used by Go and the version of the compiler need to be similar enough as per the documentation:
Users should use generated code produced by a version of protoc-gen-go that is identical to the runtime version provided by the protobuf module. This project promises that the runtime remains compatible with code produced by a version of the generator that is no older than 1 year from the version of the runtime used, according to the release dates of the minor version. Generated code is expected to use a runtime version that is at least as new as the generator used to produce it. Generated code contains references to protoimpl.EnforceVersion to statically ensure that the generated code and runtime do not drift sufficiently far apart.
The last sentence seems to imply that there is already code to ensure compatibility.
Is that correct?
That being said, I would like to be able to display the version of the library and of the compiled protobuf files in my logs to at least be able to manually verify that the versions are indeed compatible. How do I get both of these versions?
Update: Here is the section I mention in the comments.
const (
// Verify that this generated code is sufficiently up-to-date.
_ = protoimpl.EnforceVersion(20 - protoimpl.MinVersion)
// Verify that runtime/protoimpl is sufficiently up-to-date.
_ = protoimpl.EnforceVersion(protoimpl.MaxVersion - 20)
)
I am trying to build Xamarin Android binding libraries for two different RFID hand held scanner SDKs (from two different companies), and then reference them in a Xamarin.Android project. So the end goal is to have one application that can run on Device A or Device B and depending on the device manufacturer it will use a different implementation of a "scanner" interface. If I try to reference both of the resulting dlls from the Xamarin.Android project, then I get the following error:
Program type already present: com.hsm.barcode.DecodeOptions
Looking in the jars using JD-GUI as suggested in the Microsoft Docs I can see the problem is that both of the jars have a com.hsm.barcode package:
What is the best way to workaround this issue?
Note that if I use only one of the dlls then I have no issues.
What I have tried:
Using a single Xamarin Android binding library project for both jars - this gave exactly the same result
Renaming all of the classes in the jar to eliminate duplicate class names like this: <attr path="/api/package[#name='com.hsm.barcode']/class[#name='DecodeOptions']" name="name">DecodeOptions2</attr>. When I do this, in reflector I can see that the class name has indeed changed, but I still get the build error when building the Xamarin.Android project
Renaming the namespace in one of the projects: <attr path="/api/package[#name='com.hsm.barcode']" name="name">com.hsm.barcode2</attr>. Again, I can see the updated namespace in reflector but still I get the same "Program type already present" error when building the Xamarin.Android project
Similarly I have tried removing both the namespace and the duplicate classes using remove-node but seen similar results
This leads me to believe that this isn't necessarily an issue with the binding process but rather a more Android related problem. I have found some similar Android questions where people mention that you can use exclude module in gradle to remove dependencies [1] [2], but a) there seems to be no concrete answer that this is the right approach in this case and b) as I have been able to find gradle is not a tool that is used as part of the Xamarin/Visual Studio process.
My final desperate attempt to get something working was to unzip one of the jar files, remove all the .class files that are causing issues, then rezip and use this in the Android binding library and then reference this dll in my Xamarin.Android project. This seems to work (the project builds and runs) but I'm not sure it is the correct/safest/most stable solution.
To summarize, the question is: if you have two jars with duplicated namespaces/packages and you want to use both of these Jars in a Xamarin.Android project how can you avoid the resulting Program type already present: com.hsm.barcode.DecodeOptions error message.
In our project we're creating different NuGet packages (using suffixes) for different branches. In the .csproj file I'm trying to specify the specific version of a package that should be used.
Package names can be 1.2.3, 1.2.3-rc001, or 1.2.3-pr001.
First issue:
I tested using
<PackageReference Include="Package.Name" Version="[1.2.3,1.2.6)" /> where there was no 1.2.3. My understanding is it should use the next available version, but now it simply says the selected package is 1.2.3, with "Not available in this source". Updating NuGets also ignores this and simply updates to the latest release, 1.2.10. After that it overwrites the Version in .csproj, so the specified bounds are lost.
Second issue, that falls in with the first, is to specify to only use -pr* or -rc* versions. 1.2.*-pr* is not a valid option, so maybe our numbering scheme needs changing.
First issue: I tested using where there was no 1.2.3. My understanding
is it should use the next available version, but now it simply says
the selected package is 1.2.3, with "Not available in this source".
Actually, when you set different versions of a nuget package by floating versions(in your situation, 1.2.3<=version<1.2.6), NuGet chooses the package that's closest to the application and ignore the others. So it will choose 1.2.3 regardless of whether it exists in your current nuget caches.See this document.
So PackageReference will not reference the package based on the closest available version in your current cache and choose the newest version not matter whether it exits under your local machine.
Second issue, that falls in with the first, is to specify to only use
-pr* or -rc* versions. 1.2.-pr is not a valid option, so maybe our numbering scheme needs changing.
At the moment, prerelease versions cannot be used together with floating versions.It means that you cannot use any pre-release characters with floating versions . So -pr* and -rc* are illegal including 1.2.*-pr*.
During use, no characters about the pre-release version can appear.
Instead, you can use
1.2.*-*
Besides, the 1.2.*-beta1 is also illegal. Though it shows a version under Dependencies UI, you can not find it under Nuget Package Manager-->Installed which means that the package is missing and the project has lost it.
In addition, there is a similar issue which you can refer to.
I am converting my .Net 4.5 class library to .Net Standard Library 1.2 (as we want to support Cross platform.
Few of my classes and interfaces use attributes ContractClassFor and ContractClass. These classes belongs to System.Diagnostics.Contracts. But I can not find thess classes in XAMARIN.
What are the equivalent classes for those I can use? Or if no classes present, how can I replace the code with ?
Thanks so much
If you are using .NETStandard, you need to use NuGet packages for any missing namespaces. In your case you would need to install the System.Diagnostics.Contracts NuGet to unlock the desired functionality.
As the NuGet description says, it provides the ContractClass and ContractClassFor attributes you are missing.
I have a project which interfaces to external hardware using an API supplied by the manufacturer. Recently a new version of the hardware came out with a slightly modified API. I need to be able to connect to both versions.
I copied the 2 versions of the API into 2 folders in the project:
Libs
+--APIv2
+--APIv4
and added project references to the DLLs in APIv4. My intention is to access the v2 API dynamically using reflection.
The strange thing is that, although I add the v4 API from the APIv4 folder as references, it is always the v2 API which is actually referenced. The Path attribute of the reference is the path to the v2 API - /Libs/APIv2.
However, if both versions are stored outside of the project and the v4 API is referenced then this does not happen. ie if I reference v4, then v4 is actually referenced.
Can anyone explain why this is happening?
I just found out that I can set an attribute on each reference: Specific Version = true. This seems to resolve my problem.