In my u-sql script I'm using the JsonExtractor that have a reference to "Newtonsoft.Json", in this script I also use a Custom Processor that uses "Newtonsoft.Json" too.
The problem is that the version used in the Processor is different from the version used by the JsonExtractor and it fails when load de dependencies of "Microsoft.Analytics.Samples.Formats.Json.JsonExtractor".
Is there a way to redirect assemblies?
Each U-SQL database can only contain one version of any given assembly. For example, if you need both version 7 and version 8 of the NewtonSoft Json.Net library, you need to register them in two different databases. Furthermore, each script can only refer to one version of a given assembly DLL. In this respect, U-SQL follows the C# assembly management and versioning semantics.
You can find more info here:
https://learn.microsoft.com/en-us/azure/data-lake-analytics/data-lake-analytics-u-sql-programmability-guide#requirements
In your custom processor just declare an alias for your version, and then you can use multiple dependencies by version. Is it possible to reference different version of the same assembly into a single project?
Related
For example, I have trouble similar to this
Error BC32207 The project currently contains references to more than one version of 'Microsoft.EntityFrameworkCore', a direct reference to version 6.0.1.0 and an indirect reference to version 6.0.6.0. Change the direct reference to use version 6.0.6.0 (or higher) of Microsoft.EntityFrameworkCore. BackendAPI G:\Projects\ChestMax\BackendAPI\BackendAPI\Controllers\ContainerController.vb 17 Active
How is possible resolve this issue once and for any future of this project?
Dll hell
I have a library, that target NETSTANDARD2_0 that used by full NET461 and NETCOREAPP2_0 clients.
I want to add to the library some Core2.0 specific code.
I am going to add APPNETCORE2_0 target and wrap the section with
#if NETCOREAPP2_0
#endif
It will create 2 separate target DLLs.
When I will refer my library from client Core2.0 application , will it refer NETCOREAPP2_0 DLL and ignore NETSTANDARD2_0 dll?
Is the order of selecting the version predefined and documented?
I will appreciate a link to the documentation.
Here is the official doc on creating these multi-targetted dlls. That explains how a different dll is generated for each target (such as net461 and netcoreapp1.0).
The official doc on how nuget resolves these to find the matching library covers how the right dll is selected:
When NuGet installs a package that has multiple assembly versions, it tries to match the framework name of the assembly with the target framework of the project.
If a match is not found, NuGet copies the assembly for the highest version that is less than or equal to the project's target framework, if available. If no compatible assembly is found, NuGet returns an appropriate error message.
Side note: you want NETCOREAPP2_0, not APPNETCORE2_0.
I've been working on a VS Code extension that uses Roslyn's workspace API to load a project, at the moment the extension supports .NET Core's old project.json format via the ProjectJsonWorkspace type in the Microsoft.DotNet.ProjectModel.Workspaces package.
With the new tooling changes being released soon I'm keen to support the new .csproj build format but can't appear to find a .NET Standard compliant workspace that supports it.
My understanding is that as it's using MSBuild, I will need to use the MSBuild (Microsoft.CodeAnalysis.MSBuild) package, however it does not support .NET Standard at this moment in time.
What is the best solution if one exists, or will I have to look at creating my own workspace implementation?
Having spoken with various people it appears that there is no .NET Standard compatible MS Build workspace, this can be seen by this answer below to the following GitHub issue:
We haven't done the work to make MSBuildWorkspace work properly with the new MSBuild cross-platform. In the meantime, you might look at what omnisharp does to populate it's workspace.
So it seems that at the time of writing if you want to target the MSBuild workspace in a .NET Standard compliant project then you'll need to build your own custom workspace using Roslyn's workspace API, this is exactly how OmniSharp do it.
Update (16/10/2017):
Whilst MSBuildWorkspace does still not support .NET Standard, there is a library called Buildalyzer that works cross-platform and will generate an AdhocWorkspace for you, allowing you to achieve the same goal.
using Buildalyzer.Workspaces;
// ...
AnalyzerManager manager = new AnalyzerManager();
ProjectAnalyzer analyzer =
manager.GetProject(#"C:\MyCode\MyProject.csproj");
AdhocWorkspace workspace = analyzer.GetWorkspace();
The same library will also allow you to reference a solution file too.
I am following the answer here. I have downloaded the latest Quartz.dll and it is referenced in my project. I have no issues with the first part of the code (the service part) but it can't find JobDetail, SimpleJob and CronTrigger (the job part of the answer above).
Things you might check if you get a compilation error:
Do you have a mismatch in .NET versions?
Does the referred assemblies require a full .NET profile (and you only have a client profile)?
Does the referred assemblies build target type match your code? (For example, are they build for 32bit only, and you target 64bit only)
In all of my other .net apps my build process (a mixture of nant and custom tasks) automatically updates the [AssemblyVersionAttribute] AssemblyInfo.cs with the current build number before the call to msbuild, stamping in the build number in the version number.
I'm now working on my first BizTalk project and I'd like to do the same thing with the version numbers of the BizTalk assemblies, but I've run into trouble!
First of all the aseembly version numbers are stored in the btproj files, so I did some googling and found www.codeplex.com/biztalk which looked like the answer to my problem, but there is a deeper problem!
I have a project for my schemas and another for my pipelines, the pipelines project references my schemas project as I have a flat file dis/assemblers. The problem comes when I update the version numbers, as updating them even from within visual studio does not update the pipeline components references to the schemas.
So if I update all the version numbers manually in the VS IDE from 1.0.0.0 to 1.1.0.0, the build fails as the pipeline components flat file dis/assemblers still reference the old 1.0.0.0 version of the schemas! They don't automatically update!
Is this really a manual process of updating the version numbers of the BizTalk projects in the property pages, then building the projects and manually updating the references to them in the properties of all the pipeline components that reference them?
This means that I can't have my build process control the build number part of my version numbers!
Or is there a better method of managing the version numbers of the BizTalk assemblies?
I'm sorry to disappoint you but I've been down the exact some road I had to give up. I guess it could be possible to achieve it but it would require a lot of changes to both the binding files and other XML files (as you mentioned and even more if you have published services etc).
Maybe it could be possible to wrap all these necessary changes in a build step (a MSBuild step or similar in other build frameworks) - that would be useful!
Developer- :)
We had the similar problem and we ended up developing a small utility which would change the version number in all the projects i.e. *.csproj (asssemblyinfo.cs), *.btproj accordingly. Apart from this it would open and modify the *.btp files with the new version of schemas. In nutshell, what all you have to do is to configure this utility in your VS.net tools menu and execute it.
I guess its not very difficult to develop such utility in any .net lanagauge.
Caveat: Do not forget to save the files after updates with the same encoding as they were originally.
Cheers!
Gutted, thought that might be the case. Maybe BizTalk 2009 projects will play more nicely when updating references when changing version numbers.
I started to go through and automate it manually, and when I realised what needed to be done, I took a biiig step back when I realised just how many places I'd have to modify to get it working. Thank god for Undo Checkout.
I do have a standard C# class library included in my project (various helper functions), which i am able to update the version number of during my build process, so I'm basically using that one assembly to version the whole application. If anyone wants to know what version is in any environment, check out the version number of that one assembly.
Not ideal, but it's working.
We've done this successfully on our project - I'll see if I can get the developer of the tool to post details...
This problem arises when you perform an integration build to the latest versions of your dependent components as file references (aka schemas here).
Keep in mind that upgrading the assemblyversion must always performed manually, that way you are always in charge of changes to assemblyversions.
A possible solution to solve the buildbreaks issue is to file reference to a specific version of a dependent component build and not to the latest version and use a subst drive and a copy script to get the latest component builds.
For example:
SchemaA, assembly version 1.0.0.0
PipelineA (with pipelinecomponent XMLValidator for example), assembly version 1.0.0.0
PipelineA has a file reference to a subst drive(say R drive, which maps to a workspace D:\MyComponents) and version 1.0.0.0 of SchemaA as follows:
R:\SchemaA\1.0.0.0\SchemaA.dll.
The copy-script copies the buildoutput of SchemaA locally to your R drive.
When schema A updates to version 1.1.0.0 you don't have any issues because you still use version 1.0.0.0 and YOU have the choice to use the 1.1.0.0 version of your schema. When you want to upgrade, you have to alter your copy-script and replace the file reference to R:\SchemaA\1.1.0.0\SchemaA.dll.