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.
Related
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.
I am trying to work an F# tutorial on Pluralsight (see screencaps) where you have to install Xunit and write the tests but it's not working for me. It works fine for someone using Visual Studio as shown in the screencaps below, but I am not using Visual Studio. I'm on a Linux system using Monodevelop and I get this message: Composition error: the type 'Object' is required here and is unavailable. You must add a reference to assembly 'System.Runtime, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'
I think it must be the Assembly.fs file where I'm supposed to add the reference but I am not sure, nor do I know exactly how to add this reference correctly. Furthermore, I am unsure if the problem may be due to Monodevelop not recognizing a valid Linux path and if so, how to fix that. Any help would be greatly appreciated because I'm completely stuck.
Here is the error I'm getting in Monodevelop:
As already mentioned in the comments, there is not enough information in your answer to give you a proper question. The error generally happens when you add reference to a dll that is itself referencing another dll and you do not have a reference to the other dll. So in general, you can fix this by adding the reference (as mentioned in the error message).
The specific assembly that you're getting an issue on is a core library referenced by portable .NET libraries. Try adding a reference as discussed for example here.
Otherwise, you need to give us more information - what type of project are you creating (what .NET version and profile) and what other libraries are you referencing in your project.
I'm deploying a C# website to Azure from a GitHub repository. This website references a couple of F# libraries and they compile just fine on my machine, but in Azure the build fails with a number of compilation errors.
Here is a snippet of the build log:
FS0001: A generic construct requires that the type 'Company' have a public default constructor [C:\DWASFiles\Sites\eureka-servicestack-poc\VirtualDirectory0\site\repository\Eureka.ServiceStack.FSharp.Poc\Services\Services.fsproj]
C:\DWASFiles\Sites\eureka-servicestack-poc\VirtualDirectory0\site\repository\Eureka.ServiceStack.FSharp.Poc\Services\CompaniesService.fs(28,17): error FS0039: The field, constructor or member 'PopulateWith' is not defined [C:\DWASFiles\Sites\eureka-servicestack-poc\VirtualDirectory0\site\repository\Eureka.ServiceStack.FSharp.Poc\Services\Services.fsproj]
C:\DWASFiles\Sites\eureka-servicestack-poc\VirtualDirectory0\site\repository\Eureka.ServiceStack.FSharp.Poc\Services\AppHost.fs(17,55): error FS0072: Lookup on object of indeterminate type based on information prior to this program point. A type annotation may be needed prior to this program point to constrain the type of the object. This may allow the lookup to be resolved. [C:\DWASFiles\Sites\eureka-servicestack-poc\VirtualDirectory0\site\repository\Eureka.ServiceStack.FSharp.Poc\Services\Services.fsproj]
An error has occurred during web site deployment.
The first error should have been fixed after I put the CLIMutable attribute on the offending record type and the second error should have been fixed after including the proper namespace. I don't know what exactly the third error is about, especially since none of them happen locally.
To make sure I had the same version of F# in both places I've included the FSharp.Core dll in the solution and refer to the local version. This did not help but it removed a warning that it could not find version 4.3.1 of the file.
Is it possible that I'm running another version of the F# compiler and how do I check that? It has worked fine until now, which makes me suspect some slight difference in versioning of something. Unfortunately it seems quite hard to get insight into what actually happens in the build environment. It is a free website Azure website and it does not seem like you cen get direct access to it.
I could probably work around the individual issues for now but there seems to be a deeper issue at work here.
This turned out to be an issue with different versions of the F# compiler being used. Using Visual Studio 2013 RC, I was using the 3.1 version, which has had some improvements causing my specific issues to not appear.
The problem was made difficult to identify because changing my F# project to use the 3.0 compiler in Visual Studio did not have any effect (it still compiled just fine). I even opened the solution up in Visual Studio 2012, and it all compiled well enough. It was only when I created a new project from scratch in VS 2012 that I began to get the same compilation errors as on the server. So I guess that this must be an error (or at least not very desirable feature) in the project file that was created. I'm not sure if this should be classified as a bug with VS 2013, especially since I don't know exactly what causes the error.
So the simple solution until Azure (or is this a Kudu thing?) supports the 3.1 compiler is to either recreate the project file in VS 2012 or to copy code which does not compile over to a test solution where fixes can be tested.
I am working on a C++/CLI project with VS 2012 in Dynamic Library (.dll) and x64 mode.
If I switch the mode to Static Library, I get the error below.
Error 1 error C1107: could not find assembly 'mscorlib.dll': please specify the assembly search path using /AI or by setting the LIBPATH environment variable C:\Depot\Main\Current\Sln\ALibraryProject\Stdafx.cpp 1 1 ALibraryProject
I tried removing the reference to the mscorlib.dll then adding it again from:
Project > Properties > General > Common Properties
But that didn't help. As I know that VS handles the reference to the .NET assemblies, I don't want to add a disk file reference to it as it seems illogical! Did anybody face this before?
I had the same problem when converting my solution from the VS2010 compiler to VS2013 compiler.
I resolved it by changing the project settings (for the project containing the managed .cpp file that was throwing this error) as follows: In Project Settings | C/C++ | General | Additional #using Directories I added the macro $(FrameworkPathOverride). This resolves to the reference assembly directory for the version of .NET that you're targeting, which in my case is C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework.NETFramework\v4.5.1
If I switch the mode to Static Library
This is not the typical error you get when you try to build a static library with /clr in effect. I'd have to assume you've been tinkering with project settings to get rid of the inscrutable linker errors you get when you try to do this.
Core issue is that the C++/CLI build system doesn't support static libraries that contain MSIL. Managed code doesn't use a linker, binding happens at runtime. Which makes the essential difference between static libraries and DLLs disappear. So Microsoft decided to not support it because it didn't make much sense to implement it. Unfortunately they don't yell loud enough when you try to do it anyway, the linker errors you get don't give enough of a hint what you did wrong. Workarounds, like merging with ILMerge don't work either, it cannot deal with mixed-mode assemblies. Merging the native code sections and their associated relocation table entries is very untrivial.
Keep in mind that it is fine to link native static libraries. A typical C++/CLI project has only the ref class wrappers that need to be built with /clr in effect. You can glue any amount of native code from libraries into the final assembly.
I'm forced to theorize about the actual compile error, too many programmers get this error for another reason that doesn't have anything to do with building static libraries and they are harassing me in the comments.
Do beware that targeting a different version of .NET than the one you have installed on your machine is quite a hazardous affair, particularly so if you want to target 4.0 and you have 4.5.x installed. The key element in your .vcxproj file is the <TargetFrameworkVersion>. This will be missing if you started the project targeting an old .NET version, you have to insert it yourself. The IDE also doesn't support changing it if it is present, again edit by hand.
Which is enough to coax MSBuild into generating the proper compile command. You can verify if that panned-out well, look in the *.tlog subdirectory of the Debug build directory for your project. The cl.command.1.tlog file shows the options that were passed to the compiler. It should contain:
/AI"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework.NETFramework\v4.0"
/FU"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework.NETFramework\v4.0\mscorlib.dll"
Note the subdirectory, very important that it matches your intended .NET target. v4.0 in this example. And very, very important that it does not point to c:\windows\microsoft.net, the legacy location for reference assemblies.
I have the same problem. Having a dll doesn't work, as I need to provide a native C++ wrapper for a .net object so it can fulfil a natice c++ interface - I can't use .net in a dll interface - this gives a compile error
This worked as a static library in VS 2010 (with .net 4)
Some of my executables and dlls which also have some code with /clr. They don't have an issue. I'm not trying to make a net Lbirary.
I solved it by removing dependency in old and not updated mixed lib, which was also configured only in Debug configuration, and as result, it started to get the same error as yours after I changed some code.
It was not simple to find it, because error is not clear, and the dependency was set up via "Additional Dependencies" in project settings.
Open visual studio and unload your project then Go to the project folder and open file .vcxproj . Search for tag "targetFrameworkVersion"
(if not present it means ur project is not using dot net frameworks.so no requirement of change)
Change it to required version
Save the file.
And now reload the project .
I'm using third party libraries that I obtained well before KB2465367 came out. My development computer has been updated with KB2465367 so all the binaries I generate seem to now be dependant on 8.0.50727.5592 of the CRT (the 2465367 version of the CRT).
Now, when I want to deploy this application I'm using the 8.0 CRT merge module (also updated by 2465367). This installs 8.0.50727.5592 versions of MSVC libraries (like msvcrt80.dll).
But, when I run my application on a machine that's never had the VC runtime installed, it complains about "This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem." I've traced this back to a system entry in the event log: "Generate Activation Context failed for C:\Program Files\MyCompany\MyApp.exe. Reference error message: The operation completed successfully." under the source "SideBySide".
Of course, this update has basically meant I'm dead in the water.
How do I proceed from here? Do my clients need to install 8.0.50608.0 version of the CRT after installing my application because the 3rd party libraries need 8.0.50608.0 and the MSM I used didn't include it?
In my circumstance I'm using How To: Install the Visual C++ Redistributable with your installer which only describes using a single MSM. It's recommended that a policy MSM also be used to redirect any DLLs dependant on older versions of the runtime.
See also http://lynk.at/jlqsKx
This is the same thing happened when MS rolled out KB971090.
A simple solution is to remove the KB2465367.
You can reference more information about KB971090 and KB2465367 at here.
There is an uninitialized data bug in the patch that can cause DLL load failure.
Your installation program have to use two merge modules:
The runtime libraries, and
The policy file which redirects all older versions of the runtime to the new version.
The redistributable package vcredist_xxx.exe installs both the latest version of the libraries and the policy files.
You cannot assume the VC libraries are available on users machines, therefore you always have to install them. Otherwise your application won't run.