Now that native code can have assemblies (e.g. "unmanaged assembly") for side-by-side cache usage, I'm interested in changing the version of a DLL after it is built (as part of an incremental build auto-versioning scheme). I think I'm close using this commmand:
mt -updateresource:MyNewlyBuiltThing.dll;#2 -identity:"MyNewlyBuiltThing, version=5.5.0.1"
That command gives me the following error:
mt.exe : general error c101008d: Failed to write the updated manifest to the resource of file "MyNewlyBuiltThing.dll". Access is denied.
That command is executed from a command prompt with administrator privileges, and I have no anti-virus software on my development box (and the file does not have a read-only flag set).
Perhaps the problem is that I'm using the wrong name in the identity string. After all, when I load the embedded resource of the binary into Visual Studio, it shows a manifest that doesn't bother to mention its name - it only mentions the names of dependencies.
Anyway, I was just wondering if the mt.exe could be coaxed into giving me the post-build version-bumping of a non-managed assembly. Any insight of what I'm doing wrong? And if this is not possible, why?
If permissions issues have been ruled out:
Are you running on a FAT filesystem? There may be issues if not on NTFS. Also, several issues of this type are gone with the latest mt.exe, part of the "Microsoft Windows SDK for Windows 7 and .NET Framework 4", version 7.1 so you could try that.
Related
This has been killing me for the last couple of days. I have read everything I can find on this error and have done what xamarin says but it still doesn't work.
I can't get my builds to get through azure pipeline xamarin.ios build and deploy to apple.
When I build locally I get messages like
MTOUCH : warning MT1502: One or more reference(s) to type 'UIKit.UIWebView' already exists inside 'Xamarin.Forms.Platform.iOS, Version=2.0.0.0, Culture=neutral, PublicKeyToken=null' before linking
with a companion message that says no references after linking
when I use --warn-on-type-ref=UIKit.UIWebView with the optimize arg.
When I build on azure in my pipeline, I only see the MT1502 but nothing saying anything after linking. The build gets submitted to Apple and fails because of the ITMS message.
I don't know what to do. I am using the latest macOS vm image, mono 6.8.0.123, xamarin.ios 13.16.0.13, xcode 11.4.1. The pipeline worked fine before April 30 deadline, now no matter what, I can't get the linker to strip UIWebView.
Let me know what other info would be helpful. I am completely stuck at this point.
Thanks.
I just got my build to pass Apple's inspection.
What ended up working for me was building locally and packaging the ipa file. On my mac I then changed the ipa extension to zip and unzipped it. I used terminal to go to the YOURAPPNAME.app "folder" and used grep -r UIWebView . to search for references. Don't forget the . so it searches the current directory. I missed that at first and got some message that grep was listening on stdin.
For me that resulted in a line like this:
Binary file ./Frameworks/PersonalizedAdConsent.framework/PersonalizedAdConsent matches
Now, the important thing to note is the linker never warned about this, so I was completely unaware of it. In my case it was part of Firebase/Admob. I was only one release behind and updating to the latest fixed my problem.
I still am using --optimize=force-rejected-types-removal --warn-on-type-ref=UIKit.UIWebView -warnaserror:1503 as my mtouch args. But builds now get through.
I hope this helps point you guys in the right direction, I've spent the last 3 days just trying to get builds to upload reading every post I could find on the web on this problem.
Solved !! I had to update the way how nugets are included to the iOS project .csproj file. The problem was that linker despite the --optimize=force-rejected-types-removal flag was not removing the UIWebView component form Xamarin.Forms 4.6 probably because it did not see it.
My project was created over two years ago and I was still using the packages.config file. After the update the flag started to work and grep query returned 0 :). The best way is to compare the old .csproj file with freshly created iOS project .csproj file and see how VS is referencing nugets.
I am developing a UWP. I am using the sqlite-net-pcl library. After upgrading my Application from RC to RTM , I got a runtime error - sqlite3.dll could not be found - if it runs on a Mobile emulator or a device. It worked prefectly after I added a reference to C++ 2013 Runtime Package and I ran it in Local Machine.
Exception Message:
Message "The type initializer for 'SQLitePCL.raw' threw an
exception." string
The innerexception message:
{"Unable to load DLL 'sqlite3': The specified module could not be
found. (Exception from HRESULT: 0x8007007E)"} System.Exception
{System.DllNotFoundException}
Of course I could not add a referece to 'Sqlite for Universal App Platform' because I am geting the following error
Severity Code Description Project File Line Error Payload contains
two or more files with the same destination path 'sqlite3.dll'. Source
files: C:\Program Files (x86)\Microsoft
SDKs\UAP\v0.8.0.0\ExtensionSDKs\SQLite.UAP.2015\3.8.11.1\Redist\Debug\ARM\sqlite3.dll
C:\Users\sMavrikis.nuget\packages\SQLitePCL.raw_basic\0.7.1\build\native\sqlite3_dynamic\winrt81\arm\sqlite3.dll TestApp1
Add a reference to 'SQLite for Universal App Platform'
This will trigger the error:
Payload contains two or more files with the same destination path 'sqlite3.dll'.
This error occurs because of different version of sqlite3.dll in both the locations marked by the error.
Resolve this error by simply copying
C:\Program Files (x86)\Microsoft SDKs\UAP\v0.8.0.0\ExtensionSDKs\SQLite.UAP.2015\3.8.11.1\Redist\Debug\ARM\sqlite3.dll
to
C:\Users\%USERNAME%\.nuget\packages\SQLitePCL.raw_basic\0.7.1\build\native\sqlite3_dynamic\winrt81\arm\sqlite3.dll
overwriting existing file.
Rebuild your project. It should compile now.
If you look at the two conflicting locations, one seems to be coming from a more official Microsoft extension for UWP, while the second is coming from a nuGet package.
When I encountered this error, I needed the functionality of the nuGet package, so I decided to keep it and drop the other reference. I right clicked on the project in the solution explorer and went to Add->Reference and then unchecked the reference to SQLite. Seemed less error prone than copying the file from one location to the other to me.
I was getting the same error messages. I had started by using SQLite-PCL which also required SQLite for Universal App Platform as a reference. Later I switched to SQLite.Net-PCL. That is when I got those errors. In researching a solution I found this page. It worked for a bit. Eventually I removed the Reference to SQLite for Universal App Platform and the errors went away.
late reply, but had the issue now; What fix it for me was to do Nuget Package update on all the project in the solution as one of the packages was still using the old reference and was pulling through to the Running project referencing the other project that was out of date.
I fixed a similar issue by selecting x64 or arm in the compiler configuration.
Error Payload contains two or more files with the same destination path 'e_sqlite3.dll'. Source files:
C:\Users\xleon.nuget\packages\SQLitePCLRaw.lib.e_sqlite3.v140\1.1.0\runtimes\win10-arm\native\e_sqlite3.dll
C:\Users\xleon.nuget\packages\sqlitepclraw.lib.e_sqlite3.v140\1.1.0\runtimes\win10-x86\native\e_sqlite3.dll
but this, of course, won´t allow you to run the emulator
Right-Click on the UWP Project and choose Properties.
And make sure the Solution Platform target matches the Project Platform target.
If they are different you will get the build error about copying files to the same destination with the same name (but different target platforms).
I managed to solve the disparity by putting a conditional in the UWP .csproj for including the SQLite dll
<SDKReference Include="SQLite.UWP.2015, Version=3.19.3" Condition="'$(Configuration)'=='Debug'">
<Name>SQLite for Universal Windows Platform</Name>
</SDKReference>
I needed to run with the UWP version for debugging, else my XAMl designer would blow up with "Can't find SQLite.dll..."
I have a Windows Phone 8 app that utilizes SQLite. The app has many database functions, and includes a sqlite database file which, upon running the app, is copied to the local folder and accessed. All of this worked with no problem until I first switched to release build, upon which it did not work.
I "fixed" this by deleting all NuGet references and .dll references and started over following the steps here:A Workaround to Use SQLite in a Windows Phone 8 Application
I am having a frustrating problem where, after switching from debug to release build, or vice versa, 'Sqlite' is once again no longer recognized.
I get the following errors:
The type or namespace name 'Sqlite' could not be found (are you missing a using directive or an assembly reference?)
These errors are coming from SQLite.cs, specifically these lines:
using Sqlite3 = Sqlite.Sqlite3;
using Sqlite3DatabaseHandle = Sqlite.Database;
using Sqlite3Statement = Sqlite.Statement;
How is this possible? I saw some similar questions on here, but all of them simply said to delete and re-add the references and the problem inexplicably goes away. This is not working for me.
Follow this article to configure your project. Also explained here
Second you will need to go to the GITHUB website and download the
code for SQLite-net-wp8. This is a c++ project you will need to
access a sqlite database.
Make you sure you set Conditional compilation symbols: USE_WP8_NATIVE_SQLITE and release is x86 or ARM.
Tested on VS Profesional 2013, Release build (x86, ARM)
Go thorough bellow link
Windows Phone 7 Native Database Programming via Sqlite Client for Windows Phone
Hope it will help you
This one’s a head scratcher. Here’s the deal.
While deploying a beta copy of an ASP.NET application built with Delphi 2007 for .NET to a test server I encountered an odd problem. The application was unable to start because it could not load the correct version of an ADO.NET data provider that I was using.
Only by including a version of the old assembly in the bin directory would the application run. However, I don’t want to be tied to this older .NET data provider, so I am determined to find a solution to this problem.
I originally compiled the project with the .net data provider assembly used as Copy Local, which should have caused Delphi to use a copy of that version of the assembly that I selected when I added it to the References folder in the Project Manager. The actual assembly that I selected was version 9.10.2.0, and that is the version of the assembly that appears in the bin directory, along with the application. However, at runtime the application was trying to bind to an earlier version of the same assembly, 9.0.2.7.
(Actually, this problem occurs whether or not I use the GAC version of Copy Local, so I don’t think this is the issue.)
While investigating this problem I created a new project, and added a reference to the 9.10.2.0 assembly. Still, both the .NET 2.0 Configuration Utility and Reflector showed that the application compiled with a reference to the 9.0.2.7 assembly.
Inspecting the GAC I saw that both 9.0.2.7 and 9.10.2.0 versions were registered. Attempting to remove the 9.0.2.7 version fails, since that version of the provider was still referencing the assembly in the GAC.
I went into the registry and manually removed all references to the 9.0.2.7 provider. I then was able to delete it from the GAC. This didn’t change anything. Removing the assembly from an existing application and then adding the 9.10.2.0 version back, then compiling, still resulted in the wrong assembly information being inserted into the application. As before, creating a new application that referenced the 9.10.2.0 assembly didn’t work, as a reference to 9.0.2.7 was still being inserted into the executable.
I’ve checked the Delphi library search path. I also removed every instance of the old assembly files from the machine altogether (including from the ASP.NET Temporary Files directory). I still got the problem. I tried using Issam Ali’s AppManifest utility to manually adjust the manifest, but apparently it does not support ASP.NET applications in Delphi 2007 for .NET.
So, the GAC no longer contains references to 9.0.2.7, there are no references to it in the registry, there are no paths to the old provider directory in the project or Delphi options dialogs, the old provider assembly is not on the file system, and 9.0.2.7 does not appear in any of the project files. Nor does it appear in web.config, machine.config, or any other file I checked. Nonetheless, Delphi insists on using this version of the assembly anytime I reference the 9.10.2.0 version of the assembly. (Yes, I restarted Delphi, and also restarted the Virtual Machine in which this development was being performed.)
Even after uninstalling the 9.10.2.0 data provider (the older one was already uninstalled), and reinstalling it, adding the data provider reference to an application results in the runtime application attempting to load the old provider (even though no reference to the old provider apparently remains in the system).
I’ve tried other solutions (which are worth mentioning here), but none worked. Anybody seen this? I am going to continue working on this problem, but I’d love to hear suggestions. I just can’t get Delphi to stop inserting the old assembly information into the project.
For grins I’m including the error log from the failure. This log essentially duplicates the information I get from the fusion log. This log is from one of the simple apps I created after removing the 9.0.2.7 assembly from the GAC. Notice that it’s looking for the old version of the provider from the outset.
Assembly manager loaded from: c:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\mscorwks.dll
Running under executable c:\windows\microsoft.net\framework\v2.0.50727\aspnet_wp.exe
--- A detailed error log follows.
=== Pre-bind state information ===
LOG: User = TRAINING8A\ASPNET
LOG: DisplayName = Advantage.Data.Provider, Version=9.0.2.7, Culture=neutral, PublicKeyToken=e33137c86a38dc06
(Fully-specified)
LOG: Appbase = file:///C:/Inetpub/wwwroot/TestAdsVer2/
LOG: Initial PrivatePath = C:\Inetpub\wwwroot\TestAdsVer2\bin
Calling assembly : TestAdsVer2, Version=1.0.3572.17384, Culture=neutral, PublicKeyToken=null.
LOG: This bind starts in default load context.
LOG: Using application configuration file: C:\Inetpub\wwwroot\TestAdsVer2\web.config
LOG: Using host configuration file: c:\windows\microsoft.net\framework\v2.0.50727\aspnet.config
LOG: Using machine configuration file from c:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\config\machine.config.
LOG: Post-policy reference: Advantage.Data.Provider, Version=9.0.2.7, Culture=neutral, PublicKeyToken=e33137c86a38dc06
LOG: Attempting download of new URL file:///c:/WINDOWS/Microsoft.NET/Framework/v2.0.50727/Temporary ASP.NET Files/testadsver2/07545aea/3d068a5/Advantage.Data.Provider.DLL.
LOG: Attempting download of new URL file:///c:/WINDOWS/Microsoft.NET/Framework/v2.0.50727/Temporary ASP.NET Files/testadsver2/07545aea/3d068a5/Advantage.Data.Provider/Advantage.Data.Provider.DLL.
LOG: Attempting download of new URL file:///C:/Inetpub/wwwroot/TestAdsVer2/bin/Advantage.Data.Provider.DLL.
WRN: Comparing the assembly name resulted in the mismatch: Minor Version
ERR: Failed to complete setup of assembly (hr = 0x80131040). Probing terminated
This has gone on so long that the comments that I added to LanceSC's answer are no longer showing. But I do thing this is an interesting item that I want to address.
Here's my last two comments to LanceSC
The installation that exhibited this behavior is in a VM that is no longer functioning. Another developer I know experienced this same problem. The solution was to abandon the installation. I feel that something in the installer of the particular version of this .NET data provider left some strange artifact that produced the problem. It does not happen with any other build of this data provider. I am no longer pursuing an answer to this question.
Spoke too soon. A colleague of mine, today (March 5, 2010), encountered this same error, with a slightly earlier version of this same .NET data provider (9.0.2.1). He is now in the same position I was. He cannot run his application with any version of the data provider, save the old one. That assembly was being used as a local copy, and the old version is not in the gac. Using his machine, we ran the run MSBuild with the verbose option. The build worked fine with no errors. Nonetheless, the compile application failed to run, having failed to find the old version of the provider.
Summary
My colleague resigned himself to reinstalling Delphi 2007 (fortunately, he was working in a VM, and had a second VM with Delphi 2007 in which the offending .NET data provider had never been installed. This was also my tactic.
At this point, I have concluded that this problem is not solvable. Nonetheless, I am leaving this question open for another week or so. If no feasible solution is proposed in the next few weeks, I will close this question.
In the meantime, I have asked my colleague to preserve the VM with the misbehaving provider, in order to test any solution or investigation that is proposed.
Delphi 2007 uses MSBuild to perform the actual builds; however, the code in their product that syncs changes between the IDE and MSBuild is very brittle. My suspicion is that the build files are out of sync with the IDE. An easy way to update them is as follow:
Open your registry editor go to
HKEY_LOCAL_MACHINE\SOFTWARE\Borland\BDS\5.0\Globals
Change the value of ForceEnvOptionsUpdate to 1.
Open the RAD Studio IDE.
In order to confirm my suspicion you need to locate the files that Delphi.NET feeds to MSBuild. They are located somewhere under the current user's profile. You may also want to look at options in the Delphi help to have it do a verbose MSBuild output.
Have you tried grep'ing the Delphi and .NET framework directories for 9.0.2.7 to see if it is in a config file somewhere?
Something like:
grep -d 9\.0\.2\.7 *.xml
Other places you might search:
search the project files for 9.0.2.7
registry search for 9.0.2.7, and a search using the public token
If this app uses the BDP you might also search the BDP config files
I ran into something very much like this, and it drove me absolutely up the wall for days. I had a reference to Oracle.DataAccess.dll that was resolutely stuck pointing at an old version, regardless of what was in the GAC, in the search path, etc. No amount of restarts of modifications to the .dproj files would ever work.
What I eventually found was that the offending piece that was holding on to the old reference was the generated Oracle.DataAccess.dcpil in the C:\Users\Public\documents\rad studio\5.0\dcp directory.
It was over a year old - whatever the case was, Delphi did not want to write over it.
Once I deleted it, Delphi merrily created another one, and sure enough, it now points to the assembly I want it to.
Ugh, frustrating!
My PyQt application works fine when running on Linux, when in my Windows build environment, or frozen on the machine where it was build with py2exe. But after moving the frozen executable and its supporting files to another machine it can't load the database driver.
It worked fine when I had Python2.5 and an earlier version of PyQt and py2exe. But after upgrading my toolchain I get these errors:
dbname.open returns false
lastError(dbname) is "Driver not loaded"
I have an sqldrivers folder where I put qsqlite4.dll. This was necessary with the previous build environment, but moving or renaming that DLL doesn't change any behavior. I think that's the DLL that Qt can't find, but I haven't been able to tell Qt where to look.
I am currently running these versions:
python-2.6.3
PyQt-Py2.6-gpl-4.6-1
py2exe-0.6.9.win32-py2.6
Profiling in Dependency Walker gives me this error:
LoadLibraryW("\application\sqldrivers\qsqlite4.dll") returned NULL. Error: This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem (14001).
When I ask Dependency Walker for details about Qsqlite4.dll it says:
Error: The Side-by-Side configuration information for "\application\sqldrivers\QSQLITE4.DLL" contains errors.
That would explain why the DLL won't load, but I'm still unclear how to fix it. Closer inspection shows that error for most of the DLLs I call. Do I need to include a manifest for each Qt DLL I load?
Thanks in advance.
DEAR PEOPLE FROM THE FUTURE: Here's what we've figured out so far ...
The accepted answer doesn't really say what dlls they copied and in what places. I managed to fix it by copying the driver inside the sqldrivers directory relative to where the exe and qt dlls are (I'm using PySide but should work with PyQt4 as well). In setup.py:
setup(
...,
data_files = [('sqldrivers', ('C:\Python27\Lib\site-packages\PySide\plugins\sqldrivers\qsqlite4.dll',))],
...,
)
I solved it!
I had a really clever way to avoid making my users install vcredist--I copied the manifest and the DLLs into two places and all the errors about the MS DLLs went away. That's when I started trying to figure out this SQLite driver error.
I wasn't as smart as I thought. If I install vcredist all the "Driver Not Loaded" and "No SQL drivers found" errors go away. Arg.
Try to re-install SOLite, or verify if you have putted the DLL in the correct place, because i remember that the MySQL DLL have to be in System32 directory to develop something that uses it.
Regards.