In my SSIS packages, I've a script task which references the below assemblies...
Microsoft.SqlServer.DTSRuntimeWrap, Microsoft.SqlServer.ManagedDTS, Microsoft.SqlServer.ScriptTask
How can i get the same package to work on multiple SQL Server environments (For eg. SQL Server 2014, 2016 etc)?
At the moment, the packages were developed by referring to v12 assemblies. When i run those packages on a SQL 2016 box, I keep getting the below errors..
Description: CS1705 - Assembly 'Microsoft.SqlServer.ManagedDTS, Version=13.0.0.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91' uses 'Microsoft.SqlServer.DTSRuntimeWrap, Version=13.0.0.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91' which has a higher version than referenced assembly 'Microsoft.SqlServer.DTSRuntimeWrap, Version=12.0.0.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91', d:\Program Files (x86)\Microsoft SQL Server\130\SDK\Assemblies\Microsoft.SQLServer.ManagedDTS.dll, 0, 0
I tried to upgrade my 2008 package to 2016 and had a similar error on my script task. What I did was delete the old reference to Microsoft.SqlServer.ManagedDTS.dll and add a new reference from C:\Windows\Microsoft.NET\assembly\GAC_MSIL\Microsoft.SqlServer.ManagedDTS\v4.0_13.0.0.0__89845dcd8080cc91\Microsoft.SqlServer.ManagedDTS.dll
Related
I was building a wpf application on ADO pipeline agent Windows2022-DEV
Here is the error and warning I got:
##[error]XXXManager\Assets\XXTC_Modern_Resource_Dictionary.xaml(239,26): Error MC3074: The tag 'Interaction.Behaviors' does not exist in XML namespace 'http://schemas.microsoft.com/xaml/behaviors'. Line 239 Position 26.
C:\agent\_work\2\s\XXXManager\XXXManager\Assets\XXTC_Modern_Resource_Dictionary.xaml(239,26): error MC3074: The tag 'Interaction.Behaviors' does not exist in XML namespace 'http://schemas.microsoft.com/xaml/behaviors'. Line 239 Position 26. [C:\agent\_work\2\s\XXXManager\XXXManager\XXXManager.csproj]
Done Building Project "C:\agent\_work\2\s\XXXManager\XXXManager\XXXManager.csproj" (default targets) -- FAILED.
Primary reference "Microsoft.Expression.Interactions, Version=4.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL".
[warning]C:\Program Files\Microsoft Visual Studio\2022\Enterprise\MSBuild\Current\Bin\Microsoft.Common.CurrentVersion.targets(2302,5): Warning MSB3245: Could not resolve this reference. Could not locate the assembly "Microsoft.Expression.Interactions, Version=4.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL". Check to make sure the assembly exists on disk. If this reference is required by your code, you may get compilation errors.`
I searched the web and I guess this error may caused by the blend SDK is not installed on the agent Windows2022-DEV.
https://www.nuget.org/packages/Expression.Blend.Sdk
So, what command should I use in the pipeline YML file to install the blend SDK nuget package into the agent edWindows2022-DEV? Thanks.
I am trying to port 6 class libraries developed under .Net 4.5.2 to .Net 5.00 using VS 2019. I chose .Net 5.00 (and VS 2019) as my final goal is to deliver the solution as a web assembly. I have set the target framework for each of the libaries to .NET 5.0.
One of my class libraries uses Winforms so I have downloaded the Nuget package Winforms.Wasm (1.0.191137.60) by Roozbeh Gh into VS 2019.
On building I initially got the error:
1>C:\Users\howar_000\.nuget\packages\winforms.wasm\1.0.19137.60\build\netstandard2.0\Winforms.Wasm.targets(13,5): error :
Unhandled Exception: Mono.Cecil.AssemblyResolutionException: Failed to resolve assembly: 'System.Windows.Forms, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null'
... at Mono.Cecil.BaseAssemblyResolver.Resolve(AssemblyNameReference name, ReaderParameters parameters)
... at Driver.Import(String ra, AssemblyKind kind)
... at Driver.Run(String[] args)
... at Driver.Main(String[] args)
I was able to get past this problem by adding:
<PropertyGroup>
<CopyLocalLockFileAssemblies>true</CopyLocalLockFileAssemblies>
</PropertyGroup>
as per instructions I found on the Winforms.Wasm GIT repository recommended by Roozbeh Gh.
1>C:\Users\howar_000\.nuget\packages\winforms.wasm\1.0.19137.60\build\netstandard2.0\Winforms.Wasm.targets(13,5): error :
Unhandled Exception: Mono.Cecil.AssemblyResolutionException: Failed to resolve assembly: 'System.Formats.Asn1, Version=5.0.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51' 1>C:\Users\howar_000\.nuget\packages\winforms.wasm\1.0.19137.60\build\netstandard2.0\Winforms.Wasm.targets(13,5): error : at Mono.Cecil.BaseAssemblyResolver.Resolve(AssemblyNameReference name, ReaderParameters parameters)
... at Driver.Import(String ra, AssemblyKind kind)
... at Driver.Import(String ra, AssemblyKind kind)
... at Driver.Import(String ra, AssemblyKind kind)
... at Driver.Import(String ra, AssemblyKind kind)
... at Driver.Run(String[] args)
i.e. it just moved the problem along to another library distributed along with Winforms.Wasm. I have also tried to explicitly exclude the Nuget version of the System.Formats.Asn.dll but this hasnt worked either.
I realise the problem is that the Nuget Winforms.Wasm package includes netstardard2.0 libraries so that the package download is as a complete standalone distribution. Further that VS 2019 MSBuild is identifying a clash with the dotnet net5.0 distribution.
I have done a lot of investigation trying to resolve this problem - even overwriting
C:\Program Files\dotnet\packs\Microsoft.NETCore.App.Ref\5.0.0\ref\net5.0\System.Formats.Asn1.dll
with
C:\Users\howar_000.nuget\packages\system.formats.asn1\5.0.0\lib\netstandard2.0\System.Formats.Asn1.dll
and visa versa but to no avail.
But reading through swathes of literature on the web, I came to the realisation that this is a recurring problem that has plagued developers trying to use VS with .Net and Nuget packages for some time. Surely either Microsoft need to change the implementation of VS MSBuild to accommodate Nuget packages or Nuget package writers need to come up with a VS compliant distribution - rather than leaving developers spending many hours trying to establish work arounds and understand the inner works of VS MSBuild.
I am thinking of moving away from VS 2019 to use the Mono Developer toolkit - I will let you know how I get on.
Any help/suggestions on how best to migrate .Net 4.5.2 assemblies that use Nuget packages to equivalent web assemblies would be much appreciated.
I've been trying to generate the Entity Framework Models for an existing Database.
I'm using the EntityFrameworkCore.Jet-Provider (v2.1.0 preview 5) with EntityFrameworkCore (v2.1.2) in Visual Studio 2017. I used the following command within the Package Manager Console:
PM> Scaffold-DbContext -Connection "Provider=Microsoft.ACE.OLEDB.12.0;Data Source=C:\..\workplace\TestProject\demo.accdb;Jet OLEDB:Database Password=****;" -Provider EntityFrameworkCore.Jet -OutputDir Models -verbose
which gave me this output:
Using project 'TestProject'.
Using startup project 'TestProject'.
Build started...
Build succeeded.
...
Using assembly 'TestProject'.
Using startup assembly 'TestProject'.
Using application base 'C:\..\workplace\TestProject\bin\Debug'.
Using working directory 'C:\..\workplace\TestProject'.
Using root namespace 'TestProject'.
Using project directory 'C:\..\workplace\TestProject\'.
Using configuration file 'C:\..\workplace\TestProject\bin\Debug\TestProject.exe.config'.
Finding design-time services for provider 'EntityFrameworkCore.Jet'...
Using design-time services from provider 'EntityFrameworkCore.Jet'.
Finding design-time services referenced by assembly 'TestProject'.
No referenced design-time services were found.
Finding IDesignTimeServices implementations in assembly 'TestProject'...
No design-time services were found.
System.InvalidOperationException: Der 'Microsoft.ACE.OLEDB.12.0'-Provider ist nicht auf dem lokalen Computer registriert.
...
Microsoft.EntityFrameworkCore.Design.OperationExecutor.OperationBase.Execute(Action action)
Der 'Microsoft.ACE.OLEDB.12.0'-Provider ist nicht auf dem lokalen Computer registriert.
Which translates to
The 'Microsoft.ACE.OLEDB.12.0' provider is not registered on the local machine.
At first I expected this to be the case and did some research which brought me here and I followed the given solution, but the Problem persisted. Looking into the folder C:\Program Files (x86)\Common Files\microsoft shared contains the subfolders OFFICE12, OFFICE14 and OFFICE16 which each hold an ACEOLEDB.DLL.
Confirmed through use in a Code First approach the provider is actually registered and usable! But when used in the Package Manager it can't be found. Am I missing some specific reference?
Since the exact same ConnectionString is working when used with CodeFirst what could be the Issue? Or is EntityFrameworkCore.Jet not enabled for Database-First Approach?
Revisiting this Issue, I realised that the Compile Configuration had been set to Any CPU.
Mind that I have installed office 32bit and the corresponding 32bit driver set (see this and this)
While Code First will run in the Any CPU Configuration, the Package-Manager-Console does have a problem with this. PMC seems to be trying to resolve the x64-provider in this configuration.
Switching this setting to x86 in Visual Studio 2017 resolved that issue:
Using assembly 'TestProject'.
Using startup assembly 'TestProject'.
Using application base 'C:\..\workplace\TestProject\bin\x86\Debug'.
Using working directory 'C:\..\workplace\TestProject'.
Using root namespace 'TestProject'.
Using project directory 'C:\..\workplace\TestProject\'.
Using configuration file 'C:\..\workplace\TestProject\bin\x86\Debug\TestProject.exe.config'.
After switching the Compile Configuration of the Project/StartupProject to x86 PMC is able to resolve the Microsoft.ACE.OleDb.12.0 provider and successfully scaffold the database.
After upgrading to the latest tools, runtime and SDK (5.5.216.0), PowerShell scripts, such as TestConfiguration.ps1, fail with an error that Microsoft.ServiceFabric.Internal.Strings.dll version 5.0.0.0 can't be found. As soon as I deinstall 'Microsoft Service Fabric' from the control panel, it works just fine. This behavior seems very similar to the Newtonsoft.Json.dll issue that was resolved in 5.5.216.0, just with a different assembly this time around.
Is this a known issue?
It quickly gets tedious to have to uninstall 'Microsoft Service Fabric' when I run certain scripts and then have to install it again for others that require it.
Example of error:
PS C:\git\sf-admin\DeploymentScripts\Microsoft.Azure.ServiceFabric.WindowsServer> .\TestConfiguration.ps1 ..\ClusterConfig.Production.Shared.json
Trace folder doesn't exist. Creating trace folder: C:\git\sf-admin\DeploymentScripts\Microsoft.Azure.ServiceFabric.WindowsServer\DeploymentTraces
Running Best Practices Analyzer...
Standalone package dependent files not found. Check package structure. Error: System.IO.FileNotFoundException: Could not load file or assembly 'Microsoft.ServiceFabric.Internal.Strings, Version=5.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or on
e of its dependencies. The system cannot find the file specified.
File name: 'Microsoft.ServiceFabric.Internal.Strings, Version=5.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'
at Microsoft.ServiceFabric.ClusterManagementCommon.ValidatorExtensions.ThrowValidationExceptionIfNull[T](T parameter, String parameterName)
at Microsoft.ServiceFabric.DeploymentManager.BPA.BestPracticesAnalyzer.IsJsonConfigModelValid(StandAloneInstallerJsonModelBase config)
Thanks,
Hans
I believe you're getting that error due to the SDK/Runtime installing dll's to the GAC which are being picked up.
Try running moving your Microsoft.Azure.ServiceFabric.WindowsServer folder to another machine and running TestConfiguration.ps1 again.
If you're running the scripts from a box without internet access then you'll need to specify the location of the .cab which contains the runtime
-FabricRuntimePackagePath C:\temp\Microsoft.Azure.ServiceFabric.WindowsServer.5.5.216.0\MicrosoftAzureServiceFabric5.5.216.0.cab
I'm trying to implement Universal Windows Platform application with EntityFramework and SQLite (according to: http://ef.readthedocs.org/en/latest/platforms/uwp/getting-started.html) but I have problem with Add-Migration command.
Here is my setup:
Visual Studio 2015 Update 1
EntityFramework.SQLite: "7.0.0-rc1-final"
Error that I got while adding migrations is:
Could not load file or assembly 'System.Collections.Immutable, Version=1.1.36.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
Thanks in advance for your help!
It is clearly that you miss a dll "System.Collections.Immutable, Version=1.1.36.0" in your project.
To solve this problem, you can open the Nuget tool, and search for System.Collections.Immutable, then in the "Version" label select the Version 1.1.36, by default it is the latest version 1.1.37.
You can also try to update your VS tool, this possible may also solve your problem.