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.
Related
I am trying to use Matab module compiled as .Net assembly in a .Net Core Project, but I receive the following exception:
Unhandled Exception: System.IO.FileNotFoundException: Could not load
file or ass embly 'MWArray, Version=2.17.1.0, Culture=neutral,
PublicKeyToken=e1d84a0da19db8 6f'. The system cannot find the file
specified. at ConsoleAppCore1._1.Program.Main(String[] args)
MCR_R2017b_win64_installer.exe is installed on the system and I am able to load same Matlab module in .Net4.5 project.
Any clue to make it work with .Net Core1.1?
Simply NO - mathworks supports only "classic"/desktop .net framework on Windows platforms
Please refer to this: mathworks doc
Running update-database from the Package Manager Console on an ASP.NET MVC Web Application fails after I add an unrelated Wix setup project to my solution.
Why is update-database accessing this unrelated project? Why does the presence of the wix project trigger a load of an assembly that cannot be found? How do I fix this?
This happens in a larger solution with web, desktop, installer projects, but after considerable head-scratching I reproduced this in isolation:
Setup a new stock-standard VS solution with an ASP.NET MVC Web Application, Entity Framework, enable migrations, add WebMatrix components, setup Role provider.
Add Configuration.Seed() method to call out to WebMatrix.WebData.WebSecurity.InitializeDatabaseConnection(..) and System.Web.Security.Roles.
Run update-database. It will work fine. Now add a Wix setup project (no need to configure) and it will fail at/before executing Seed() with
Could not load file or assembly 'Microsoft.Build.Framework, Version=15.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified.
So, it seems having a Wix project in my solution triggers the load of an additional (not found) assembly when trying to call WebSecurity / WebMatrix methods through update-database from the Package Manager Console.
Workaround: Unload the Wix setup project and restart Visual Studio. There is no need to remove the project entirely.
Adding the missing dll to the GAC or a reference to the machine.config does not help. The dll is found but loading it errors out with
System.IO.FileLoadException: Loading this assembly would produce a different grant set from other instances. (Exception from HRESULT: 0x80131401)
Using FUSLOGVW.exe to log assembly load events didn't help. It basically shows that update-database can't find the v15.1 dll because it's not in the GAC and there is no app/host/system config file pointing at it.
Running the seed method from the running web application (enable automatic migration) works fine.
And yes, I am setting PMC "default project" to the web application, ie, point update-database at the web application.
Details:
Visual Studio Professional 2017 on Win 10 Pro fully patched.
Recently upgraded VS from 2015. No such problem under 2015.
Wix Toolset 3.11.0.1528
Package Manager Console 4.1.0.2427
System.Web.Mvc 5.2.3.0
Entity Framework 6.1.3
WebMatrix.Data.dll 3.0.0.0
WebMatrix.WebData.dll 3.0.0.0
Microsoft.Build.Framework.dll v15.1.0.0 lives in C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\15.0\Bin\ and Visual studio has a redirect to it in its app.config.
Snippets:
Configuration.cs:
class Configuration : DbMigrationsConfiguration<MyDbContextHere>
{
public Configuration() { AutomaticMigrationsEnabled = false; }
protected override void Seed(Stash context)
{
WebSecurity.InitializeDatabaseConnection("DefaultConnection", "UserProfiles", "UserId", "UserName", autoCreateTables: true);
if(!Roles.RoleExists("G1")) Roles.CreateRole("G1");
}
}
`
web.config:
`
<configuration>
<system.web>
<roleManager enabled="true" defaultProvider="SimpleRoleProvider">
<providers>
<clear />
<add name="SimpleRoleProvider" type="WebMatrix.WebData.SimpleRoleProvider, WebMatrix.WebData" />
</providers>
</roleManager>
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 previously had all unit tests for my solution contained in a single library, and were recently split out. When located in a single assembly, all tests passed both locally and on TeamCity, but when seperated there are version conflicts.
Config:
Team City 7.1.5 (build 24400)
AutoFixture 3.20.2
AutoFixture.AutoMoq 3.20.2
Moq 4.2.1402.2112
NUnit 2.6.3
I have several unit test assemblies, which all reference a base test library. All test assemblies use the NuGet packages listed above.
When running tests on a dev machine (VS 2015), all tests pass successfully.
When running a team city build, the following error is thrown:
System.IO.FileLoadException : Could not load file or assembly 'Moq, Version=4.1.1308.2120, Culture=neutral, PublicKeyToken=69f491c39445e920' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040) at Ploeh.AutoFixture.AutoMoq.MockPostprocessor.Create(Object request, ISpecimenContext context)
There is no reference to Moq 4.1.1308.2120 anywhere in my solution, so I know it must be a reference from AutoFixture.
Updating AutoFixture to 3.31.3 makes no difference.
I have the following Binding Redirect in the app.config files of all test assemblies:
<dependentAssembly>
<assemblyIdentity name="Moq" publicKeyToken="69f491c39445e920" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-4.2.1402.2112" newVersion="4.2.1402.2112" />
</dependentAssembly>
I cannot downgrade my version of Moq to 4.1.1308.2120 as I use features of 4.2 in my tests.
It appears to me that Team City is ignoring the redirects. I have no idea why, and having tried every combination of version for these assemblies I cannot get Team City to run the tests successfully.
We ran into this problem as well. We ran the assembly Fusion Logs on our build server and saw this in the error logs:
Calling assembly : Ploeh.AutoFixture.AutoMoq, Version=3.50.2.0, Culture=neutral, PublicKeyToken=b24654c590009d4f.
===
LOG: This bind starts in default load context.
LOG: No application configuration file found.
LOG: Using host configuration file:
LOG: Using machine configuration file from C:\Windows\Microsoft.NET\Framework\v4.0.30319\config\machine.config.
LOG: Post-policy reference: Moq, Version=4.1.1308.2120, Culture=neutral, PublicKeyToken=69f491c39445e920
LOG: GAC Lookup was unsuccessful.
LOG: Attempting download of new URL file:///D:/builds/13/s/AssessmentMigratorService.IntegrationPostbuild/bin/Debug/Moq.DLL.
LOG: Assembly download was successful. Attempting setup of file: D:\builds\13\s\AssessmentMigratorService.IntegrationPostbuild\bin\Debug\Moq.dll
LOG: Entering run-from-source setup phase.
LOG: Assembly Name is: Moq, Version=4.5.28.0, Culture=neutral, PublicKeyToken=69f491c39445e920
WRN: Comparing the assembly name resulted in the mismatch: Minor Version
ERR: The assembly reference did not match the assembly definition found.
ERR: Run-from-source setup phase failed with hr = 0x80131040.
ERR: Failed to complete setup of assembly (hr = 0x80131040). Probing terminated
So if you see this part of it
No application configuration file found.
what I think is happening is that the unit test runner host application on the build server is not seeing the application configuration file and so the assembly binding redirects are not able to apply, since they are in the app.config.
So I see 3 possible solutions/workarounds if you need to use these assemblies:
Figure out why TeamCity's unit test runner on the build server cannot find the application configuration file and fix that.
Use a different unit test runner on the build server.
Add the binding redirects to the machine.config of the build server. That will apply globally on the entire machine, so there is no need for the redirects in the application configuration file at that point.
I was embarrassed when I discovered the reason that I was seeing this error.
After 8 hours debugging I found that I had referenced TestProjectB in TestProjectA. Teamcity was set up to run any xunit against any Test*.dll that it found. So it found the TestProjectB.dll in TestProjectA's /bin/Debug folder.
But there is no TestProjectB.dll.config for TestProjectB.dll when it is in /TestProjectA/bin/Debug. Hence none of the assembly binding/redirect where being set.
I remove the project reference because it was unnecessary and updated my teamcity xunit runner to exclude dlls that don't have a matching config.
I did this:
Created new WebAPI project in Visual Studio 2013
Package Manager Console: Install-Package HangFire
Package Manager Console: Install-Package HangFire.Mongo
Put the example code in Global and created the example Startup class described here https://github.com/sergun/Hangfire.Mongo
When I compile I get the error The type or namespace name 'Mongo' does not exist in the namespace 'Hangfire' for Hangfire.Mongo namespace, but I clearly have the reference.
You probably are using an old target framework. It happened the same thing to me a while back.
Check your project properties -> Application -> Target framework and make sure it's at least .NET Framework 4.5.1