3

After the update of Entity Framework to version 6.4.4 the migrate.exe was replaced with ef6.exe. This made a breaking change in my release pipeline in Azure DevOps. I've tried to update the migration command from originaly working

$(System.DefaultWorkingDirectory)/_IdentityServer-CI-Build/drop/migration/migrate.exe Identity Identity.Migrations.AspNetIdentity.Configuration /connectionString=$(connectionstring) /connectionProviderName="System.Data.SqlClient"

to current version

$(System.DefaultWorkingDirectory)/_IdentityServer-CI-Build/drop/migration/ef6.exe database update --verbose --assembly Identity.dll --connection-provider "System.Data.SqlClient" --connection-string '$(connectionstring)'

running on a copy of $(Build.SourcesDirectory)\packages\EntityFramework.6.4.4\tools\net45\any\ef6.exe.

Unfortunatelly I'm getting an error

System.Data.Entity.Tools.CommandException: Your target project 'Identity' doesn't reference EntityFramework. This package is required for the Entity Framework Core Tools to work. Ensure your target project is correct, install the package, and try again. ---> System.IO.FileNotFoundException: Could not load file or assembly 'EntityFramework' or one of its dependencies. The system cannot find the file specified.

According to the error it seems to me the tool is not suitable for .NET Framework projects. Since there is practically no documentation for using this tool on .NET Framwork projects, I've checked the source code to at least get the parameters, but I have no idea what to do about this error or what different approach to use to do the update from the pipeline.

Andree
  • 1,159
  • 2
  • 17
  • 32

2 Answers2

3

Utilizing the 6.4.4 version of ef6.exe executed migrations for:

database update --verbose --assembly Identity.dll --migrations-config Identity.ClientConfiguration.Configuration --project-dir 'D:\drop\Identity' --connection-string '$(connectionstring)' --connection-provider "System.Data.SqlClient"

user1689338
  • 31
  • 3
  • 1
    This did not work for me because the assembly is not found unless you specify the full path to the dll file (absolute or relative to the working directory). – Adrian H. Mar 15 '22 at 14:33
1

It seems that the assembly is not relative to --project-dir, therefore you have to specify the full path for the assembly.

See this answer: https://github.com/dotnet/ef6/issues/1605#issuecomment-597910149

Afterwards I got another error on my local machine (but this did not happen on Azure DevOps):

System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.IO.FileLoadException: Could not load file or assembly 'Server, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. Operation is not supported. (Exception from HRESULT: 0x80131515) ---> System.NotSupportedException: An attempt was made to load an assembly from a network location which would have caused the assembly to be sandboxed in previous versions of the .NET Framework. This release of the .NET Framework does not enable CAS policy by default, so this load may be dangerous. If this load is not intended to sandbox the assembly, please enable the loadFromRemoteSources switch. See http://go.microsoft.com/fwlink/?LinkId=155569 for more information.

To fix this, I had to open the file properties and unblock the file (see https://stackoverflow.com/a/45221477/581553):

enter image description here

Adrian H.
  • 569
  • 6
  • 17
  • Oh wow, I would never ever have found that. Thanks for posting. Apparently this can be done through PowerShell quite easily: https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.utility/unblock-file , needed to do this during an Octopus deploy :) – René Sackers May 04 '22 at 12:07