How to make SqLite work in Windows 10 at the publication - c

There is a classic application where Microsoft is used.Entity Framework Core.Sqlite, trying to publish an application through Windows 10 deployment and throws an exception: DllNotFoundException: Unable to load DLL "e_sqlite3": the specified module could not be found. (Exception from HRESULT: 0x8007007E)
Tried adding e_sqlite3 library to " Windows application packaging Project", in end face with the exception: SQLite Error 14: 'unable to open database file' with EF Core code first
I tried different solutions found on the Internet, but not one I did not fit.
Development environment:
Windows 10, Visual Studio 2017, Microsoft.EntityFrameworkCore.Sqlite 2.2.1.0 and Microsoft.Data.Sqlite 2.2.1.0

Here's how I solved both issues.
The first issue is that the native e_sqlite3.dll files are not copied to the Package project's output. The Package project has MSBuild logic in Microsoft.DesktopBridge.targets that is calling the GetCopyToOutputDirectoryItems target of each of its referenced projects (e.g. a WPF project). Since the e_sqlite3.dll files are being included in the referenced project by way of a NuGet package, the way in which they are being included doesn't cause them to be picked up by the GetCopyToOutputDirectoryItems target. I've worked around this by adding the following code to my WPF project:
<Target Name="IncludeNativeBinariesAsOutput" BeforeTargets="GetCopyToOutputDirectoryItems">
<ItemGroup>
<Content Include="$(OutputPath)\x64\e_sqlite3.dll">
<Link>x64\e_sqlite3.dll</Link>
<CopyToOutputDirectory>Always</CopyToOutputDirectory>
</Content>
<Content Include="$(OutputPath)\x86\e_sqlite3.dll">
<Link>x86\e_sqlite3.dll</Link>
<CopyToOutputDirectory>Always</CopyToOutputDirectory>
</Content>
</ItemGroup>
<AssignTargetPath Files="#(Content)" RootFolder="$(MSBuildProjectDirectory)">
<Output TaskParameter="AssignedFiles" ItemName="ContentWithTargetPath" />
</AssignTargetPath>
</Target>
The next issue is with the "unable to open database file" error after the necessary native files are where they need to be. I'm thinking this is because it's trying to create the project in a location that is not supported by a Windows Package project. I've handled this by setting a special value that that SqliteConnection looks for to construct a path for the database file. I just added this line to my App constructor class before doing any database operations.
AppDomain.CurrentDomain.SetData("DataDirectory", ApplicationData.Current.LocalFolder.Path);

Related

Microsoft.Bcl.AsyncInterfaces error (in CSVHelper method) when running the application installed by Visual Studio Setup project

I have a WPF application that reads a CSV file using CSVHelper which I installed using NuGet. Here's the project, system, etc version info.
Microsoft Windows 7 Professional Version 6.1.7601 Service Pack 1 Build
7601
Microsoft Visual Studio Community 2019 Version 16.4.5
NuGet Package Manager 5.4.0
WPF Project Target Framework: .NET Framework 4.7.2
CSVHelper Version: 15.0.5
CSV reader method is straightforward; read a file and put it in a list. Nothing fancy. I'll link the entire project at the bottom so you can download and try it out if you want.
When I run the executable made in either Release or Debug builds, they work fine. They read the file, put contents in a list, and display on a DataGrid just fine. As a next step, I created a standard Visual Studio Setup project, and created an msi installer, which I used to install the app in my PC.
When I run that executable (which is in my Program Files directory), however, the application throws an exception. Here's the exception message and Stack Trace.
Could not load file or assembly 'Microsoft.Bcl.AsyncInterfaces, Version=1.0.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51' or one of its dependencies. Reference assemblies should not be loaded for execution. They can only be loaded in the Reflection-only loader context. (Exception from HRESULT: 0x80131058)
at ReadCSVTest.MainWindow.ReadPeopleList(String path, List`1& people, String& msg)
at ReadCSVTest.MainWindow..ctor()
Since the error says couldn't load the assembly Microsoft.Bcl.AsyncInterfaces, I added that from NuGet and ran everything again, and I still get the error. What's the problem here? What does it mean that Reference assemblies should not be loaded for execution. They can only be loaded in the Reflection-only loader context.? And why do I only get this exception when I run the executable installed by the Setup project?
Please download the entire project from HERE.
Just so anyone runs into the same issue in the future; as Jones suggested in the comments, downgrading each of the two libraries to following versions fixed the issue for me.
CsvHelper ==> 12.3.2
And
Microsoft.Bcl.AsyncInterfaces ==> 1.0.0

VS2017 15.4 Preview "Windows Application Packaging Project" tool failed to generate a working app

I added the new "Windows Application Packaging Project" that comes with vs2017 15.4 preview.
When adding my project to the "Applications" and debugging the packaging project I have the following error:
System.IO.FileNotFoundException: 'Could not load file or assembly
'System.Runtime, Version=4.1.2.0, Culture=neutral,
PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The
system cannot find the file specified.'
InnerException: FileNotFoundException: Could not load file or assembly
'System.Runtime, Version=4.0.0.0, Culture=neutral,
PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The
system cannot find the file specified.
My project is running perfectly if I debug it directly or run it directly using the EXE.
If I extract the files from the .appxbundle and try to start the EXE, it doesn't work either. (XXXXXX.appxbundle\XXXXXX.appx\*.*)
I noticed that in the extracted .appxbundle folder, all System.XXX DLLs are not there. They should be (94 dlls are missing).
Is there a problem with the packaging tool ?
UPDATE:
Link to dev portal: https://developercommunity.visualstudio.com/content/problem/122252/windows-application-packaging-project-tool-failed.html
This is very likely a bug in the way the packaging project is collecting files. Looks like we're already tracking this bug in the Developer Community. Also, we're tracking another related issue for ClickOnce.

Automatic publish of sql server project after each build on VS2015

I am using visual studio 2015 and have a SQLServer project, what I want is that whenever i build the project it automatically gets published to sql server. In TFS we can achieve it by following
Update Build definition -> Process -> MSBuild arguments -> /t: Build /t:Publish /p:SqlPublishProfilePath = filePath.publish.xml
On local pc we can use the following command to achieve the task
msbuild ProjectName.sqlproj /t:build /t:Publish /p:SqlPublishProfilePath=filePath.publish.xml
But how can we update the build definition of the project so that when I build it on my local machine it gets published automatically without using command line
how can we update the build definition of the project so that when I build it on my local machine it gets published automatically without using command line
To accomplish this, unload your project, edit the project file ProjectName.sqlproj. Then at the very end of the project, just before the end-tag </Project>, place below scripts:
<Target Name="DeployDB" AfterTargets="build">
<Message Importance="high" Text="************** Star Deploying DB **************"/>
<Message Importance="high" Text="Deploying Project: $(MSBuildProjectDirectory)$(MSBuildProjectName).sqlproj" />
<Message Importance="high" Text="Deployment Profile: $(MSBuildProjectDirectory)PublishProfiles$(MSBuildProjectName).publish.xml" />
<MSBuild Projects="$(MSBuildProjectDirectory)$(MSBuildProjectName).sqlproj” Properties=”SqlPublishProfilePath=$(MSBuildProjectDirectory)PublishProfiles$(MSBuildProjectName).publish.xml" Targets="sqlPublish" />
</Target>
You can use some of MSBuild Reserved and Well-Known Properties like $(MSBuildProjectName) and $(MSBuildProjectDirectory), for complete list
BTW, automatic publish will slow you down, and you probably don't need to publish for every build. Under this condition, you can add a Condition for this target so that you select whether you need to automatic publish of sql server project after each build(Do not forget to add a Configuration with LocalAutoDeploy).
<Target Name="DeployDB" AfterTargets="build" Condition="'$(Configuration)' == 'LocalAutoDeploy'">

Online-only ClickOnce app not updating through web link

I'm working on a ClickOnce app that's set to online-only. I publish it to an internal IIS server, with an HTML page in the same directory that contains this link:
The deployment looks like so, with all files except the HTML page generated by my project's publish target:
MyAppName
-> Application Files
-> MyAppName_2213_20_0_65
-> <The published files>
-> default.html
-> MyAppName.application
When I click the link, the app runs immediately without any confirmation prompt, and I see from the about box that it's the old version. When I browse to the file share and launch MyAppName.application by double-clicking on it in Explorer, I get the prompt asking me if I'd like to run it, and then it downloads and I get an error:
Unable to install this application because an application with the same identity is already installed. To install this application, either modify the manifest version for this application or uninstall the preexisting application.
As part of the build process, I set the InstallUrl property of the project to http://ourserver/MyAppName/MyAppName.application. Is that wrong? Should it be the HTML page that contains the link? How is it determining the "identity" that's generating a conflict?
Since the app's online-only, it's not installed and doesn't show up in the Programs and Features control panel (and therefore that part of the error message doesn't apply).
I'm new to ClickOnce, so let me know if I left out some helpful information.
Update
If I run mage -cc from a Visual Studio command prompt, the new version launches instead of the old one.
Update 2
As I poked around more, I'm seeing something that looks wrong, and could be the problem. I see the following two lines in my MyAppName.application file (the deployment manifest):
...
<assemblyIdentity name="MyAppName" version="1.0.0.0" ...
...
<dependency>
<dependentAssembly dependencyType="install" codebase="Application Files\MyAppName_2213_20_0_65\MyAppName.exe.manifest" size="82044">
<assemblyIdentity name="MyAppName.exe" version="1.0.0.0" ...
...
You can see the mismatch above. It's deploying to MyAppName_2213_20_0_65, but it thinks the version number of the exe is 1.0.0.0. I'm not sure why it thinks that. My project includes a file that gets generated as part of the build with this line:
[assembly: AssemblyVersion("2213.20.0.65")]
Then, to set the published version number, I have this in my csproj file:
<Target Name="BeforePublish">
<GetAssemblyIdentity AssemblyFiles="$(TargetPath)">
<Output TaskParameter="Assemblies" ItemName="MyAppAssemblyInfo" />
</GetAssemblyIdentity>
<PropertyGroup>
<ApplicationVersion>%(MyAppAssemblyInfo.Version)</ApplicationVersion>
<InstallUrl>$(INSTALL_URL)</InstallUrl>
</PropertyGroup>
</Target>
Does the assembly version listed for my executable even matter? If it does, why is it stuck on 1.0.0.0, and could that be affecting the download of updated versions?
My second update put me on the right track. The problem was indeed the incorrect version number for the assemblyIdentity attributes. To fix it, I'm no longer using a BeforePublish target. Instead, I'm passing in the ApplicationVersion when I call MSBuild:
"%msbuild_path%" MyAppName.csproj /target:Publish /p:ApplicationVersion=%VERSION%

Could not load file or assembly Microsoft.Data.OData Version=5.2.0.0 error in Azure Cloud Worker Role using Table Storage

I have a very peculiar issue using Azure Table Storage. I have a .NET 4.5 project in Visual Studio 2012 where I deal with all my Azure Table Storage functions. This project/dll is referenced by two other projects, my MVC website, and my Azure Worker Role. (I am running under the Azure Emulators on my machine, but it also happens when I deploy it to the cloud)
I have the following function that is called when I save or retrieve a record:
internal static CloudTable GetTable(CloudStorageAccount storageAccount, string tableReference)
{
CloudTableClient tableClient = storageAccount.CreateCloudTableClient();
CloudTable table = tableClient.GetTableReference(tableReference);
table.CreateIfNotExists();
return tableClient.GetTableReference(table.Name);
}
In my MVC website I have a function that will save a record to a Azure Storage table, and then in my Azure Worker Role there is a service that will read the record.
So both uses the same dll for storage and retrieval, however my MVC project has no issues saving the record, but in my Azure Worker role service when it tries to retrieve the record throws the exception when it attempts to execute "table.CreateIfNotExists();".
Could not load file or assembly 'Microsoft.Data.OData,
Version=5.2.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or
one of its dependencies. The located assembly's manifest definition
does not match the assembly reference. (Exception from HRESULT:
0x80131040)
I have done the following already:
Updated all the NuGet packages from the solution level to the latest versions
I went through every project reference to make sure that there are no old dll's or previous versions hanging around, in particular the System.Spatial, Microsoft.WindowsAzure.Configuration, Microsoft.WindowsAzure.ServiceRuntime and Microsoft.ServiceBus, Microsoft.WindowsAzure.Storage, Microsoft.Data.Edm & Microsoft.Data.OData
I have even created a new Cloud Service and WorkerRole project from scratch to make sure it is not something in the current WorkerRole project that is broken.
I have not rolled the dll's back to 5.2 as I had too many issues in other projects where I use features that are specific from 5.3 onwards.
I am currently running all the dll's on 5.5.
When I run the AsmSpy.exe utility found here, I get the following output that I am not 100% sure how to interpret.
> Reference: Microsoft.Data.Edm
> 5.5.0.0 by Microsoft.Data.OData
> 5.5.0.0 by Microsoft.Data.Services.Client
> 5.5.0.0 by Microsoft.WindowsAzure.ActiveDirectory.GraphHelper.2013_04_05
> Reference: System.Spatial
> 5.5.0.0 by Microsoft.Data.OData
> 5.5.0.0 by Microsoft.Data.Services.Client Reference: Microsoft.Data.OData
> 5.5.0.0 by Microsoft.Data.Services.Client
> 5.2.0.0 by Microsoft.WindowsAzure.Storage <-- THIS SEEMS TO BE THE ONE THAT IS CAUSING ISSUES
How I interpret it, is that the Microsoft.WindowsAzure.Storage dll is referencing V 5.2.0.0 of the Microsoft.Data.OData dll, but how do I fix this, if this is the issue? According to the documentation I have seen on the Storage dll is that it is supposed to reference 5.4 and up, not 5.2...?
Opening issue for such an easy to solve issue will not help you.
Put the following addition configuration in your respective config files (web.config for the MVC and app.config for the worker role):
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="Microsoft.Data.OData" publicKeyToken="31bf3856ad364e35" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-5.5.0.0" newVersion="5.5.0.0" />
</dependentAssembly>
<dependentAssembly>
<assemblyIdentity name="Microsoft.Data.Edm" publicKeyToken="31bf3856ad364e35" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-5.5.0.0" newVersion="5.5.0.0" />
</dependentAssembly>
</assemblyBinding>
</runtime>
Note that runtime section is direct descendant of the configuration root element! I'm pretty sure you already have this section in your web.config, because MVC4 uses it to rebind all references to System.Web.MVC to the latest version.
I personally do not expect the SDK to be updated with every new version of every referenced library! This would be madness...
I had a very similar problem but in this case it exception message was;
Could not load file or assembly 'Microsoft.Data.OData,
Version=5.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or
one of its dependencies. The located assembly's manifest definition
does not match the assembly reference. (Exception from HRESULT:
0x80131040)
note it was trying to load v5.5.0.0 of the OData assembly.
After some digging around with ILSpy (http://www.ilspy.net) I discovered that Microsoft.WindowsAzure.Storage 2.0.0.0 was explictly referencing Microsoft.Data.OData 5.2.0.0 - which I didn't have as my version was 5.5.0.0.
So the solution was to use the NuGet package manager to uninstall Microsoft.WindowsAzure.Storage, this inturn uninstalled Microsoft.Data.OData 5.5. Then again using the NuGet package manager, reinstall Microsoft.WindowsAzure.Storage which identified that it needed Microsoft.Data.OData 5.2 and installed that too.
and back to a working solution.
You can solve this issue in general whenever you update packages or add new packages via NuGet and end up with "Could Not Load file or Assembly..." issues.
Open the Package Manager Console (VS 2012 Tools/Library Package Manager/ Package Manager Console). Once the shell opens for the Package Manager Console run the command:
Add-BindingRedirect
Note: Be careful as the NugGet example added an 's' to the end in their example and Add-BindingRedirect is not a valid command.
This does the following:
Examines all assemblies in the output path for a project and adds
binding redirects to the application configuration (app.config) file
or to the web configuration (web.config) file where required.
You can see complete documentation for the Package Manager Console at: http://nuget.codeplex.com/wikipage?title=Package%20Manager%20Console%20Command%20Reference%20(v1.3)
In addition to the two entries you see in astaykov's answer the following was also added for my Project.
<dependentAssembly>
<assemblyIdentity name="System.Spatial" publicKeyToken="31bf3856ad364e35" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-5.5.0.0" newVersion="5.5.0.0" />
</dependentAssembly>
I had similar problem today. The only difference I spotted is my cloud app was looking (and failing to find) for Microsoft.Data.OData in Version=5.2.0.0
Using Visual Studio Object Browser i found out that my solution used library from that location:
C:\Program Files (x86)\Microsoft WCF Data Services\5.0\bin\.NETFramework
Microsoft.Data.OData library residing there was in ver. 5.0.0.0 so overwriting it with 5.2.0.0 resolved the problem.
P.S. I installed WCF Data Services Tools for Windows Store Apps earlier in hope of resolving this issue so it may happen that your application gets it from another source. If that is the case you have two options:
Install WCF Data Services Tools for Windows Store Apps from here and use solution above.
Use Visual Studio Object Browser to find what versions of OData library are currently visible for your project and where they are stored. Next you need to overwrite improper versions of them.
I had a similar problem as well, but I wasn't using Azure and there was no hard-coded reference that was pointing to 5.2. But it resolved (after finding this article) by making sure that the text in the .svc pointed to the correct assembly:
<%# ServiceHost Language="C#"
Factory="System.Data.Services.DataServiceHostFactory,
Microsoft.Data.Services, Version=5.6.0.0,
Culture=neutral, PublicKeyToken=31bf3856ad364e35"
Service="MVC4WCFDataServiceFE5.NorthWindService" %>
Note the Version=5.6.0.0, which I didn't have before.

Resources