Heyho,
I'm working my way through Xamarin.Forms right now and today I got the following error when I tried to Release compile the UWP project of my app (Debug is working):
Payload contains two or more files with the same destination path 'System.Runtime.CompilerServices.dll'. Source files:
C:\Users\[...]\.nuget\packages\runtime.win10-x64-aot.microsoft.netcore.universalwindowsplatform\6.2.0-preview1-26926-04\runtimes\win10-x64-aot\lib\uap10.0.15138\System.Runtime.CompilerServices.Unsafe.dll
C:\Users\[...]\.nuget\packages\system.runtime.compilerservices.unsafe\4.5.1\lib\netstandard2.0\System.Runtime.CompilerServices.Unsafe.dll
The projects shared library compiles as netstandard2.0 and again includes a netstandard2.0 library itself, though I don't believe it should be a problem.
The UWP project references "Universal Windows" and the (self-compiled) SQLite.Net library. It also referenced the "Microsoft.NETCore.UniversalWindows" NuGet package, but I uninstalled it (attempting to solve the issue above).
I also tried Cleaning and recompiling the solution, removing and restoring the actual NuGet directories, adding and removing references, up- and downgrading of the UWP packages, changing the build order of my solutions projects...but nothing worked.
Does anyone have any idea what I could do here?
My main problem is that the error seems to come from .NET packages that I can't exchange/remove without crashing the whole project...
Thanks to this question I found a solution to my problem.
Though it wasn't the build target under (Project properties->Build->Build Target) for me I noticed the checkbox "Compile with .NET Native toolchain". I removed the tick and the project compiles fine for Release.
I have a Visual Studio 2017 C++ project which depends on ffmpeg libraries. As of now it crashes at run time because of the missing dependency avformat-58.dll. I've tried adding this file into the project by dragging it into my project but that does not suffice. I tried looking at the Add Reference screen but it is empty. What can I do?
On the advice of #HansPassant I added the dll(s) to the project as existing external files. I think there should now be an option somewhere to "Copy to output directory" but I'm not seeing it. Here is what I see when I open property pages of one of the dlls.
#sellotape Here is a screenshot of the window when I just single click.
According to this documentation https://learn.microsoft.com/en-us/windows/desktop/Dlls/dynamic-link-library-search-order I can copy the necessary dlls to any directory in the PATH environment variable. There were many dlls already in C:/Windows/System32 already so I just put the ffmpeg dlls there as well and the executable runs.
I've started working on a Xamarin solution (a brown-field project) in Visual Studio 2013.
One of the projects is missing a reference to monotouch.dll.
I see that the DLL can be found in the following path on my machine, but don't know if I should be referencing it directly:
C:\Program Files (x86)\Reference
Assemblies\Microsoft\Framework\MonoTouch\v1.0
I checked the GAC for the assembly and NuGet as well, but couldn't find it there.
Is it OK to reference monotouch.dll from the above folder path? Or should it be referenced another way?
Note that I have Xamarin 3.8 installed, with Xamarin.iOS 8.4. Also note that we don't want to switch to the Unified API just yet, hence the reliance on monotouch.dll
Yes. If you create a new Classic API project you will see that monotouch.dll is referenced from that path.
#Rdavisau's answer is correct, but I also disovered what went wrong. I opened the old VS2010 project in VS2013, and I think VS2013 changed my target framework references on my projects.
I fixed this by editing the CSProj file and deleting the default CSharp targets:
And only keeping the Xamarin targets:
When doing this, the Monotouch.dll is automatically referenced in the right place.
I just installed the Windows Phone developer tools, because I want to play with the phone and possibly publish some application(s).
However, after creating a default project, I'm presented this when I try to compile:
The tag 'Panorama' does not exist in XML namespace 'clr-namespace:Microsoft.Phone.Controls;assembly=Microsoft.Phone.Controls'
What mistake have I made?
EDIT: I missed part of the error:
C:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.Common.targets(1360,9): warning MSB3245: Could not resolve this reference. Could not locate the assembly "Microsoft.Phone.Controls". Check to make sure the assembly exists on disk. If this reference is required by your code, you may get compilation errors.
For SearchPath "{TargetFrameworkDirectory}".
Considered "C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\Silverlight\v4.0\Profile\WindowsPhone\Microsoft.Phone.Controls.dll", but it didn't exist.
Considered "C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\Silverlight\v4.0\Profile\WindowsPhone\Microsoft.Phone.Controls.exe", but it didn't exist.
For SearchPath "{RawFileName}".
Considered treating "Microsoft.Phone.Controls" as a file name, but it didn't exist.
For SearchPath "Bin\Debug\".
Considered "Bin\Debug\Microsoft.Phone.Controls.dll", but it didn't exist.
Considered "Bin\Debug\Microsoft.Phone.Controls.exe", but it didn't exist.
Just got this error! In my case I was manually adding some pre-existing XAML's (among them, some with panorama) to a project which didn't have any panorama page.
Basically what I did was add a new "Windows Phone Panorama Page", which made VisualStudio include some additional references that was missing, and now the project is loading smooth.
It appears to me that the SDK somehow failed to install some of the required components. I would recommend reinstalling the SDK first and see where you can get from there.
We have several external DLL files being referenced in our Web Application Project. We have a deployment project for installing on the hosting servers. When we were using .NET 3.5 and Visual Studio 2008 the DLL files were being copied to the bin folder. Since we have upgraded to .NET 4 and Visual Studio 2010 this no longer happens, and we are getting server errors since the references cannot be found.
CopyLocal is set to true, and I cannot find anything inside the web.config which suggests this is being set elsewhere.
There is a bug in Visual Studio 2010. By default the XML in the solution file looks like this:
<Reference Include="DevExpress.SpellChecker.v11.1.Core,
Version=11.1.5.0,
Culture=neutral,
PublicKeyToken=b88d1754d700e49a,
processorArchitecture=MSIL">
<HintPath>..\References\DevExpress.SpellChecker.v11.1.Core.dll</HintPath>
</Reference>
Whereas MSBuild is expecting this below, so that the DLL file will be included in the deployment:
<Reference Include="DevExpress.SpellChecker.v11.1.Core,
Version=11.1.5.0,
Culture=neutral,
PublicKeyToken=b88d1754d700e49a,
processorArchitecture=MSIL">
<HintPath>..\References\DevExpress.SpellChecker.v11.1.Core.dll</HintPath>
<Private>True</Private>
</Reference>
The trick is to set Copy Local to False, save the project and then reset it to True - save again. This includes the Private node correctly, which MSBuild respects.
It appears that the default for no included private node (Copy Local) in Visual Studio 2010 is True, while MSBuild reads that missing node as False.
I was getting the same problem and rather than add a "BeforeBuild" step I created a test that simply did this
[TestMethod]
public void ReferenceAssemblyThatDoesNotCopyToBuildFolder()
{
Microsoft.Practices.EnterpriseLibrary.ExceptionHandling.Logging.LoggingExceptionHandler referenceThisButDoNotUseIt = null;
}
And that fixed the error The type 'Microsoft.Practices.EnterpriseLibrary.ExceptionHandling.Logging.LoggingExceptionHandler...' cannot be resolved
Something weird had happened to my deployment project. When I saw it had no detected dependencies, I removed the primary output and re-added it.
The dependencies are now showing up and being placed in the bin folder when installed.
I was getting exactly the same issue. We have a Visual Studio 2008 project which references the EnterpriseLibrary. When we run our integrated build using TFS and our Web deployment project, all the DLL files are copied over. When we upgraded to Visual Studio 2010, TFS 2010 and WDP 2010, some of the DLL file's were missing. Strangely, this only occurs to some DLL files and not others.
For example, we get the Microsoft.Practices.EnterpriseLibrary.ExceptionHandling.dll copied in both cases, but not the Microsoft.Practices.EnterpriseLibrary.ExceptionHandling.Logging.dll.
As a workaround I copied the files accross using a "BeforeBuild" step.
It now seems to build OK.
I just had the same issue and wanted to share what I found as it might help someone:
The reason in my case was that the assembly was installed in the GAC during an installation of some third-party application.
If the DLL file is in the GAC, the compiler won't bother to copy it to the destination folder, unless you specifically mark it for "copy local" using the "Private" node in the project file as mentioned by Junto.
The thing is that if you don't add that node, and you develop on one machine and build on a different one, and the DLL file is only in the GAC of the build machine, the default behavior without the private node will cause the file to be copied correctly on the development machine, but not on the build machine.
The bigger problem is if the DLL file is not referenced directly, but the project references a second project that in turn references the DLL file. In that case, you cannot mark the DLL file to be "copy local" in the project, as it is not referenced by it. So if the DLL file exists in the GAC - it won't get copied to your output folder.
Possible solutions to this case are:
Uninstall the DLL file from the GAC
Add a direct reference to the DLL file in the end project(s)
Re-sign the DLL file with a new strong name, which will differentiate it from the DLL file in the GAC.
I am not sure how it was set up in Visual Studio 2008, but I am almost positive that you might have been using the Post-Build event command line. In there you can tell to copy the DLL files you need for deployment. An example is given below:
mkdir $(SolutionDir)\Deployment
copy "$(SolutionDir)Your_Library_Name\Your_Dll_ForDeployement.dll"
$(SolutionDir)\Deployment\
I didn't meet the same problem but similar. I had WPF main project and referenced project where the referenced did not copy. I found that in my case the main project was set for NET 4.0 Client Profile and the referenced for NET 3.5. When I set the main project to 3.5 the compiled dll of the referenced project started to copy.
(I don't know why because I solved it by practice)
I too ran into a similar issue where referenced dlls were not copied into the bin in published folder. I was using a TFS checked out copy that didn't include the bin folder into the application.
-> So just included the bin folder.
-> Built the referenced applications
-> Published the website project
Now I see all the referenced dlls in bin in the published folder
I had a similar issue with VS 2012 Express. I used Tesseract libraries in my project. Everything worked well until I used this project in a solution where were more than one project. Problem was that some DLLs (liblept168.dll, libtesseract302.dll) that are normally placed in folders bin/debug/x86 or bin/debug/x64 were copied only when I rebuilt whole solution.
Changing a single line and building it again caused that the DLLs were deleted and not copied back.
I solved this issue by adding a reference of the project that creates missing DLLs to the startup project.
rzen and others, thanks - your comments led to a solution for us.
We have a project that targets version 10 of the Microsoft.ReportViewer.Common.dll and Microsoft.ReportViewer.WebForms.dll assemblies (separate "libs" folder we created at the 'src' level). But when we did a build, the output included version 12, which was recently installed on the build server.
Using comments here, we ensured that 'Copy Local' was set to True and that the flag was set in the project file. However, it was still deploying version 12. So what we found that did the trick was ensuring that the 'Specific Version' property was also set on the two references. Voila, version 10 of each file is now being deployed!
There was much rejoicing.
JH
If your project does not directly load the library, it won't always be deployed, even if it is referenced explicitly! I got confused because I could see it in a local Bin directory but not when deployed. The dll in the Bin directory was an old file that wasn't removed during Clean which is why I was confused.
A full clean and rebuild and it wasn't in my local Bin folder either which showed me the problem (I only use it in web.config). I then referenced the dll file itself in the project and set it to copy to output to make sure it gets deployed.
We can use the <Private>False</Private> to not to copy the referenced DLL files to the bin directory. This is useful when we are building applications in a separate TFS build server where we need to build the application and not to copy the DLL files to the bin directory.
Check the framework of the project in which the DLL file has been referenced. The framework should be .NET 4.0. Please correct it if the framework is Client Profile.
Adding the parameter
/deployonbuild=false
to the msbuild command line fixed the issue.
Got a similar issue when upgrading old WebSites into WebApplications.
The "Clean Solution" command would wipe out all external DLL files I purposely left in my bin folders.
Besides, it was not possible to bring those DLL back automatically simply by referencing them all, since many of them have the same file name (it happens when you work with many language specific resources)
Like stevie_c did, I took advantage of the Pre-Build command, but made it simpler:
I just used a xcopy command in the Pre-Build operation of the WebApplication project's properties. This way I could bring over the necessary external DLL files just before the build would start.