Wix Setup Project breaks unrelated Migrations update-database call - entity-framework

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>

Related

How to clear dotnet-ef error file not found <project>EntityFrameworkCore.targets

I have refactored an ASP.NET Core Entity Framework code-first app to Blazor server-side using Entity Framework 6.0.0. All my CRUD operations work as intended but when I finally wanted to update the schema and perform a code-first migration to SQL Server, I ran into this strange problem.
Apparently in the obj folder of my project there is suppose to be a generated file
...\<solution folder>\<project folder>\obj\<project>.csproj.EntityFrameworkCore.targets
This file is missing and I can't seem to figure out how to get it to re-generate.
Questions
What tool is responsible for generating the <project folder>\obj\<project>.csproj.EntityFrameworkCore.targets file?
How do I force the file to regenerate?
Error examples:
dotnet-ef --version
Entity Framework Core .NET Command-line Tools 6.0.0
dotnet-ef migrations list
System.IO.FileNotFoundException:
Could not find file '/obj/.csproj.EntityFrameworkCore.targets'.
dotnet-ef migrations add init0
Could not find file '/obj/.csproj.EntityFrameworkCore.targets'
Entity Framework Nuget packages used in project:
Microsoft.AspNetCore.Diagnostics.EntityFrameworkCore Version="6.0.0"
Microsoft.AspNetCore.Identity.EntityFrameworkCore Version="6.0.0"
Microsoft.AspNetCore.Identity.UI Version="6.0.0"
Microsoft.EntityFrameworkCore Version="6.0.0"
Microsoft.EntityFrameworkCore.SqlServer Version="6.0.0"
Microsoft.EntityFrameworkCore.Tools Version="6.0.0"
Microsoft.Extensions.Diagnostics.HealthChecks.EntityFrameworkCore Version="6.0.0"
Microsoft.Extensions.Identity.Core Version="6.0.0"
The issue turned out to be Windows Defender Ransomware Protection selectively blocking dotnet.exe file and folder actions. To solve the issue I had to
Enable Controlled Folder Access
Allow an app through Controlled folder access
Add an allowed app: "C:\Program Files\dotnet\dotnet.exe"

Unable to Scaffold-DbContext with EntityFrameworkCore.Jet

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.

Entity Framework 7 with Universal Windows Platform Add-Migration

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.

Assembly version conflicts for AutoFixture and Moq with NUnit on TeamCity 7

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.

TortoiseSVN issue tracker plugin built - but not implemented

I've read all the info of how to build an issue tracker plug-in in C# for TortoiseSVN.
I done that, building a class library with integration to my issue tracking (SalesForce).
I don't know how to install it to TortoiseSVN itself.
I've created a setup for the solution and I can install it (like JIRA solution that I found online).
I don't know what is missing.
Update:
I did what you wrote, made sure everything is correct.
I don't get the name of the provider, but the GUID, and an error:
alt text http://img339.imageshack.us/img339/8558/sfsvnerror.jpg
what can it be?
1) You need to make sure that you have the right CLSIDs registered in the registry - so my installer inserts the following (fake) values:
(This, I think should be the equivalent of running RegASM as detailed at the bottom of the issue-tracker-plugins.txt file.
Installer Registry Changes Image http://img291.imageshack.us/img291/1618/registryinstaller.png
You should be able to import this registry file to get you started:
(You will probably have to dynamically update the CodeBase location, based on where the dll is installed to)
Windows Registry Editor Version 5.00
[HKEY_CLASSES_ROOT\CLSID{AAAAAAAA-AAAA-AAAA-AAAA-AAAAAAAAAAAA}]
#="FogBugzPlugin.MyPlugin"
[HKEY_CLASSES_ROOT\CLSID{AAAAAAAA-AAAA-AAAA-AAAA-AAAAAAAAAAAA}\Implemented
Categories]
[HKEY_CLASSES_ROOT\CLSID{AAAAAAAA-AAAA-AAAA-AAAA-AAAAAAAAAAAA}\Implemented
Categories{3494FA92-B139-4730-9591-01135D5E7831}]
[HKEY_CLASSES_ROOT\CLSID{AAAAAAAA-AAAA-AAAA-AAAA-AAAAAAAAAAAA}\Implemented
Categories{62C8FE65-4EBB-45E7-B440-6E39B2CDBF29}]
[HKEY_CLASSES_ROOT\CLSID{AAAAAAAA-AAAA-AAAA-AAAA-AAAAAAAAAAAA}\InprocServer32]
#="mscoree.dll"
"ThreadingModel"="Both"
"Class"="FogBugzPlugin.MyPlugin"
"Assembly"="MyAssemblyName,
Version=1.0.0.0, Culture=neutral,
PublicKeyToken=31286c9d1d5aa00a"
"RuntimeVersion"="v2.0.50727"
"CodeBase"="file:///C:/Program
Files/folder/AAAAAAAAAAAAA/MyAssemblyName.dll"
[HKEY_CLASSES_ROOT\CLSID{AAAAAAAA-AAAA-AAAA-AAAA-AAAAAAAAAAAA}\InprocServer32\1.0.0.0] "Class"="FogBugzPlugin.MyPlugin"
"Assembly"="MyAssemblyName,
Version=1.0.0.0, Culture=neutral,
PublicKeyToken=31286c9d1d5aa00a"
"RuntimeVersion"="v2.0.50727"
"CodeBase"="file:///C:/Program
Files/folder/AAAAAAAAAAAAA/MyAssemblyName.dll"
[HKEY_CLASSES_ROOT\CLSID{AAAAAAAA-AAAA-AAAA-AAAA-AAAAAAAAAAAA}\ProgId]
#="FogBugzPlugin.MyPlugin"
2) You need to make sure that the user gets the BugTraq Associations added to the registry:
[HKEY_CURRENT_USER\Software\TortoiseSVN\BugTraq Associations\0]
"Provider"="{AAAAAAAA-AAAA-AAAA-AAAA-AAAAAAAAAAAA}"
"WorkingCopy"="c:\"
"Parameters"=""
(This can also be done manually by the user by going to TSVN -> Settings -> Hook Scripts -> Issue Tracker Integration -> Add
Where "{AAAAAAAA-AAAA-AAAA-AAAA-AAAAAAAAAAAA}" is the GUID of the provider that you created.
All being well, the plugin should now be available to the user. when they open the commit dialog.
Update:
Troubleshooting the "Provider Shows As GUID" Issue seen above...
OK... so assuming your provider GUID is
{0DA7E319-1DCE-4A94-65555B5B6CE5}
You should check:
Your plugin implements IBugTraqProvider and IBugTraqProvider2 and has the GUID applied to it:
namespace FogBugzPlugin
{
[ComVisible(true),
Guid("0DA7E319-1DCE-4A94-65555B5B6CE5"),
ClassInterface(ClassInterfaceType.None)]
public class MyPlugin : IBugTraqProvider, IBugTraqProvider2
So now you should have:
GUID: 0DA7E319-1DCE-4A94-65555B5B6CE5
PluginName: FogBugzPlugin.MyPlugin
Go to regedit and have a look and see what you have in the registry. It should be along the lines of:
Windows Registry Editor Version 5.00
[HKEY_CLASSES_ROOT\CLSID\{0DA7E319-1DCE-4A94-65555B5B6CE5}]
#="FogBugzPlugin.MyPlugin"
[HKEY_CLASSES_ROOT\CLSID\{0DA7E319-1DCE-4A94-65555B5B6CE5}\Implemented Categories]
[HKEY_CLASSES_ROOT\CLSID\{0DA7E319-1DCE-4A94-65555B5B6CE5}\Implemented Categories\{3494FA92-B139-4730-9591-01135D5E7831}]
[HKEY_CLASSES_ROOT\CLSID\{0DA7E319-1DCE-4A94-65555B5B6CE5}\Implemented Categories\{62C8FE65-4EBB-45E7-B440-6E39B2CDBF29}]
[HKEY_CLASSES_ROOT\CLSID\{0DA7E319-1DCE-4A94-65555B5B6CE5}\InprocServer32]
#="mscoree.dll"
"ThreadingModel"="Both"
"Class"="FogBugzPlugin.MyPlugin"
"Assembly"="FogBugz2Tortoise, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31286c9d1d5aa00a"
"RuntimeVersion"="v2.0.50727"
"CodeBase"="file:///C:/Program Files/folder/FogBugz2Tortoise/FogBugz2Tortoise.dll"
[HKEY_CLASSES_ROOT\CLSID\{0DA7E319-1DCE-4A94-65555B5B6CE5}\InprocServer32\1.0.0.0]
"Class"="FogBugzPlugin.MyPlugin"
"Assembly"="FogBugz2Tortoise, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31286c9d1d5aa00a"
"RuntimeVersion"="v2.0.50727"
"CodeBase"="file:///C:/Program Files/folder/FogBugz2Tortoise/FogBugz2Tortoise.dll"
[HKEY_CLASSES_ROOT\CLSID\{0DA7E319-1DCE-4A94-65555B5B6CE5}\ProgId]
#="FogBugzPlugin.MyPlugin"
You should also have the ProgID / CLSID entry directly under HKCR:
Windows Registry Editor Version 5.00
[HKEY_CLASSES_ROOT\FogBugzPlugin.MyPlugin]
#="FogBugzPlugin.MyPlugin"
[HKEY_CLASSES_ROOT\FogBugzPlugin.MyPlugin\CLSID]
#="{0DA7E319-1DCE-4A94-65555B5B6CE5}"
Hope this helps - I'd check the last point first.