When I build for the iPhone simulator all seems to work fine. However, when I build for the iPhone, I get messages saying the following -
Warning MT3005: The dependency 'System.Windows, Version=2.0.5.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e' of the assembly 'Cirrious.CrossCore, Version=1.0.0.0, Culture=neutral, PublicKeyToken=e16445fd9b451819' was not found. Please review the project's references. (MT3005) (IMI.Webstore.Mobile)
This worked with previous versions of Xamarin but the current beta release seems to have broken something. Any ideas?
After reviewing the build log further, it actually wasn't a problem with finding that particular dll, even though there were warnings about it.
The issue was actually with some directory permissions due to a some what complicated windows VM setup. I ended up cloning a copy of the code base into a different directory and the issue sorted itself out. PHEW!
You need to reference System.Windows in your Touch Project.
Related
We have a .net core 3.1 solution, which we are able to compile (using Visual Studio 2019) and publish. We gave the solution to our team which is setting up the deployment process. While trying the build (linux container) they are seeing the below error:
CommonLib -> /srv/jenkins_work/DSS/ewcms/CMS/CommonLib/bin/release/netcoreapp3.1/CommonLib.dll
CSC : error CS8032: An instance of analyzer Microsoft.EntityFrameworkCore.InternalUsageDiagnosticAnalyzer cannot be created from /var/lib/jenkins/.nuget/packages/microsoft.entityframeworkcore.analyzers/5.0.9/analyzers/dotnet/cs/Microsoft.EntityFrameworkCore.Analyzers.dll : Could not load file or assembly 'Microsoft.CodeAnalysis, Version=3.7.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'. The system cannot find the file specified.. [/srv/jenkins_work/DSS/ewcms/CMS/Microsoft.EntityFrameworkCore.UnitOfWork/Microsoft.EntityFrameworkCore.UnitOfWork.csproj]
The file mentioned Microsoft.EntityFrameworkCore.Analyzers.dll is there in the folder mentioned in the error. other projects in the same solution have this as a warning, but this particular project shows it as an error.
Reading online many said to install Visual Studio, but that is something they said they can not do in the container, is there another way to get around this issue? Or something in particular we need to look at in that project which is causing and error rather than a warning?
After some investigation, turned out that project had the setting:
<TreatWarningsAsErrors>true</TreatWarningsAsErrors>
which was not there in the other projects, which were showing it as warnings only. Changed this to false and this project is also going through now, it comes up as a warning and allows the build to go through.
I am setting up a Sitecore project and when I try to view the website in the Browser I get the following error message:
Could not load file or assembly 'Owin, Version=1.0.0.0, Culture=neutral, PublicKeyToken=f0ebd12fd5e55cc5' or one of its dependencies. The system cannot find the file specified.
I understand the error, however, I am not sure why it is being thrown. Since I have included this reference for this project. I want answers of how you have overcome this error. Thanks
This is likely because you have the wrong version of the Owin.dll.
Though Sitecore out of the box doesn't depend on the Owin.dll there are some third party modules that rely on this dll particularly when concerning authentication.
I would check that you have not overwritten another version of the dll when you published the Visual Studio project to the website.
If you have binaries that depend on different versions of assemblies you can use Assembly binding redirects to target the correct version of the dll.
If I build my Visual Studio project for Xamarin.iOS with the Linker Behaviour set to "Don't Link", everything works fine except the resultant IPA file is 30MB (which expands to 101MB on the app store!).
If I change the Linker Behaviour to anything else (Link All or Link SDK) then I receive the following compile error;
Error 32 Failed to resolve "System.Void UIKit.UITableView::set_DataSource(UIKit.UITableViewDataSource)" reference from "Xamarin.iOS, Version=0.0.0.0, Culture=neutral, PublicKeyToken=84e04ff9cfb79065"
I want to use the linker so that the size of the project comes down to a respectable size. Can anyone elp with this error?
The issue was because your older version of sqlite was based on an older (preview) version of the unified API.
Some API signatures changed like, in the case, to allow using protocols more easily (which means using interfaces instead of types).
Note that turning off the linker will remove the build failure - but that symbol is still missing and you can run into this at runtime (which is worse since you'll need to test carefully to ensure that does not get hit).
I removed the reference to sqlite and re-added it again through nuget. This resolved the issue.
I currently have a VS2012 solution with a WP71 project and a WP8 project. Each of these projects reference a Portable Class Library project where I keep the view models. I also have a Unit Test project that references the PCL and contains tests for the view models.
The problem I'm having is when I compile the unit test project I get the following error:
error CS0012: The type 'System.Windows.Input.ICommand' is defined in an assembly that is not referenced. You must add a reference to assembly 'System.Windows, Version=2.0.5.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e, Retargetable=Yes'
All of the projects, including the unit test project, reference the Portable.MvvmLightLibs NuGet package.
After looking around for this assembly I noticed that there are different versions, one for WP8, one for Silverlight 4, etc. Out of all these versions I'm not sure which to use.
The unit test project is targeting .NET Framework 4.5, so I added the System.Windows assembly for that version which works, but I then get the following error:
error : CA0001 : Could not resolve reference to System.Windows, Version=2.0.5.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e, Retargetable=Yes
Seeing as this is a code analysis error I'm tempted to simply ignore this and carry on, but I was wondering if anyone had any ideas on how to solve this or whether it is safe to ignore it?
So, I figured a way to solve the problem.
To get the test project to compile I had to add the System.Windows.dll assembly from:
C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\Silverlight\v4.0\Profile\WindowsPhone71
But, adding it using the Add Reference dialog automatically adds the .NET 4.5 version even if I browsed directly to the folder. To fix this I opened the *.csproj for the test project and replaced the line:
<Reference Include="System.Windows"/>
with
<Reference Include="System.Windows">
<HintPath>C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\Silverlight\v4.0\Profile\WindowsPhone71\System.Windows.dll</HintPath>
</Reference>
This ensured that the 2.0.5.0 version was referenced instead of the .NET 4.5 version. The problem with this approach is certain types conflict with other assemblies, namely the System.dll, but seeing as I'm only testing view models from a Portable Class Library, I'm not all that bothered.
Ideally the test project would also be a Portable Class Library, but I've not got round to testing that.
One other issue was I tend to have warnings show up as errors when building in release mode, so this always fails because there will always be a warning complaining about naming clashes with System.dll.
A working web service is broken after installing ServiceStack.Logging.Log4Net with package-manager (in VS Express 2012 Web)
The exception thrown on initializing is:
Method 'Add' in type 'ServiceStack.ServiceHost.ServiceRoutes' from assembly 'ServiceStack, Version=3.9.4.0, Culture=neutral, PublicKeyToken=null' does not have an implementation.
This happened after installing logging in two different applications. (I deliberately tried breaking the second one by installing logging, just to be sure, and it did break...)
Cleaning and rebuilding the whole thing makes doesn't fix this.
Any help is welcome.
We've just re-deployed all the latest (v1.04) logging libraries for ServiceStack.Logging which now should be in-sync with the latest version of ServiceStack.Common libraries.