Everything was rolling along smoothly until a few days ago when UWP all of a sudden stopped building after pulling a new version from VSTS (git) with the errors:
Cannot resolve Assembly or Windows Metadata file 'Type universe cannot resolve assembly: X.Core, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null.'
Could not copy the file "obj\x86\Debug\MainPage.xbf" because it was not found.
Could not copy the file "obj\x86\Debug\App.xbf" because it was not found.
Could not copy the file "obj\x86\Debug\X.Mobile.UWP.xr.xml" because it was not found.
I have a solution structure of the following:
X.Core (.NET Standard class library)
X.Mobile (.NET Standard PCL)
X.Mobile.UWP (UWP specific project)
UWP references Mobile, and Mobile references Core (Core is also referenced by a web API project).
The commit that I pulled from source control did not have any changes to the X.Mobile.UWP .csproj file.
Things I have tried:
The obligatory clean and rebuild.
Delete all obj and bin folders for the entire solution.
Remove and re-add all references in the .UWP project.
Upgrade Xamarin.Forms to the latest stable (3.1.0.637273).
Remove and re-add X.Core reference in the X.Mobile project.
Delete C:\Users\%username%.nuget folder.
Update Microsoft.NETCore.UniversalWindowsPlatform to the latest stable (6.1.5).
Change the target version to all available versions - we've been running on build 16299 for several months.
And I've been beating my head against this problem on and off for days now. Android and iOS projects build just fine, which is ironic considering UWP has been our most stable platform. Anyone have any insight?
EDIT:
After adding a reference to X.Core directly to the X.Mobile.UWP project, I can compile. This shouldn't be the answer though since UWP never directly references Core.
I found the solution.
I had the very same problem because I had added a new (.Net Standard 2.0 Class Library) project into my Xamarin.Forms solution.
In short, initially my solution included the following projects:
BackgroundTaskTest (which have all my Views and ViewModels)
BackgroundTaskTest.Android
BackgroundTaskTest.iOS
BackgroundTaskTest.UWP
Suddenly I decided to add a class library named "BackgroundTaskTest.Common" in the same solution folder:
BackgroundTaskTest.Common (new one)
BackgroundTaskTest (which have all my Views and ViewModels)
BackgroundTaskTest.Android
BackgroundTaskTest.iOS
BackgroundTaskTest.UWP
The Android was working fine with it but the UWP project didn't like that new neighbor (which in your case is named "X.Core"). So I moved my classes from that new project to the "BackgroundTaskTest" again and deleted "BackgroundTaskTest.Common" from my solution with all the references and it has started working.
To finalize and make it short, please compare your X.Mobile.csproj file with X.Mobile.Core.csproj file. you will find the issue in the differences. Plus try to check all your dependencies to the X.Core project to make sure they are the same.
I installed NuGet package "NETStandard.Library" and added a reference to all my .Net Standard libraries to my UWP project. This solved the problem for me!
I am trying to convert a Windows Forms application to UWP using the Desktop Bridge. Since I have (most of) the source code, I'm attempting the conversion using Visual Studio, as opposed to the command-line tool. My application uses some third-party DLLs whose source code I don't have.
After adding a new JavaScript UWP project to my solution, I'm placing the original application's DLLs in a project subfolder as explained in the documentation.
Some of these DLLs are causing strange errors when I build the UWP project. The errors seem to be caused by duplicate resource entries in the DLLs, but curiously enough, these DLLs are referenced without issue in my standard Windows Forms project.
The errors state:
Duplicate entry
'DevExpress.Data.PropertyNamesRes/DevExpress/XtraPrinting/XpsDocumentOptions'
or one of its parents is defined as both resource and scope, which is
not allowed
I've been digging and searching about these errors for hours but I haven't found any meaningful information. I also used ILDASM to analyze the DLL headers but found no obvious issues in them. Has anyone here faced similar issues? Thanks in advance for any information.
Without seeing the complete error is difficult to say, but I've seen similar errors processing resources. If this is the case, this could be the same as this issue
And can be solved adding this property to the jsproj:
<AppxGeneratePrisForPortableLibrariesEnabled>false</AppxGeneratePrisForPortableLibrariesEnabled>
I'm trying to access a Berkeley DB database file (say Test.db) from the java code and then want to read all the pairs from it. I'm using the com.sleepycat.db.* and com.sleepycat.bdb.* packages ( NOTE: Not Oracle Berkeley DB JE )to do this task. For the implementation, I did exactly as described in this BerkeleyDB Java API Tutorial
So, when I run this project from eclipse I got this error
Exception in thread "main" java.lang.UnsatisfiedLinkError: no db_java-4.2 in java.library.path
and from the stack trace, source for this exception occured from this line
env = new DbEnv(0);
I tried to set it from the java command
$java -D<name>=<value>
but still it didn't work.
My goal is to export this project into a jar file and use it to read BDBs anywhere . Anyone who knows how to get out of this, I appreciate your help. It would be great if I can be redirected to any working tutorial for accessing Berkeley DBs from java code too. Thanks !!
SOLUTION: After a lot of work, I found out that the Sleepycat API that I'm working on is using native libraries that are written in C/C++ through the JNI. Berkeley DB that is installed on my PC didn't have the shared object file db_java-4.2 (to be accurate, file name is libdb_java-4.2) which means that this BDB is not configured for java APIs.
So, the solution is to start the installation of BDB from scratch again by enabling the java configuration.
I had the same problem.
Like kK_Pulla mentioned, the sleepycat API using native libraries written in C/C++ through the Java Native Interface. So making Sleepycat API calls means the java code is ultimately going to call compiled C/C++ code.
If you are getting the "java.lang.UnsatisfiedLinkError: no db_java-4.2 in java.library.path" error then it is likely that, at least it was in my case, you have not included the relevant native libraries in your project.
I would describe what I did to fix it in my case. Firstly let me describe my environment.
IntelliJ maven Java project on a linux machine.
Built Berkeley DB version 18.1.40.
The Berkeley build included the --enable-java switch in the configuration phase.
I included the db.jar (found in the build_unix directory) as a module dependency through the Intellij menus File> Project Structure. I selected Modules under Project settings on the left pane and then under the dependencies tab I added the db.jar file as a dependency.
This was the state of my project before I encountered the UnsatisfiedLinkError. To fix that I added the native libraries (found in the unix_build/.libs directory) to the project. You can do this by selecting the File menu> then Project Structure. On the left pane under project settings select Libraries and then click the + sign on the right pane to add the directory for the native libs.
This fixed my problem.
I made a small console app in VS 2010 and I just published it and went to install it on another pc (Win XP Sp3). The installer made me update the .Net framework, which I did and then when i went to run th second part which actually installs the app I am getting the following modal box:
Unable to install or run the application. the application requires that assembly EnvDTE Version 8.0.0.0 be installed in the Global Assembly cache (GAC) first.
Please contact your system administrator.
What in the world is EnvDTE v8.0.0.0????
This is a tiny app which does a small web call to an api and returns the results. I do make a DB call for a select and and update using some generated code from Codesmith/Nettiers (including enterprise Library). These files are referenced in the app though already.
Any ideas how to fix or work around this?
EnvDTE.dll is, as Zabba said in his comment (not sure why he didn't answer with this) used to automate Visual Studio. For some reason, you have added a reference to this in your project.
Open your solution, look at the References node in all your solution projects, and delete any reference pointing to EnvDTE.
It doesn't normally magically appear in your reference list; you either have to add it, or the project template you used to create your project referenced it, or you added an item whose template added this reference.
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!