Develop Reference

Xamarin.Forms iOS crash on XAML pages with custom controls

I am working on a Xamarin.Forms project, for which I recently upgraded the shared projects from PCL to .NETStandard.
At that point, I encountered build issues coming from several of my UI XAML files, with the error being:
Failed to resolve assembly: ‘MyAssembly, Version 0.0.0.0,
Culture=neutral, PublicKeyToken=null’
The problem files were found to be those that referenced custom XAML controls. After finding several people with similar issues online, I eventually found that I could get past this issue by setting the XamlCompilationOptions for those pages from Compile to Skip. The project now builds for iOS and Android.
The Android version works normally, however for the iOS version crashes when one of those pages tries to load, due to the presence of the custom control, with an error such as:
Xamarin.Forms.Xaml.XamlParseException … Type shared.SharedControl not
found in xlmns clr-namespace: …
Has anyone encountered this issue, and if so, did you solve it? Is it a code issue or a Xamarin / Visual Studio Mac bug?
Ideally I would like to not have to set the XamlCompilationOptions for those pages to Skip, but either way I don't see why it should affect iOS but not Android.

Firstly, XamlCompilationOptions.Compile means Compile the XAML for the class or project when the application is built.While XamlCompilationOptions.Skip do the same thing when the application is run on the device.
In addition ,I suggest that you can do following steps:
Delete and Re-generate all share files
Remove ;assembly:xxx from App.xaml
Clean and build again.
Here is a similar thread for you referring toXamarin.Forms.Xaml.XamlParseException has been thrown
PS:There is a link about how to Upgrade PCL to .NET Standard Class Library

You need to load that assembly before using it. On Xaml it does not load, just try to reach, and crashes if its not loaded. Before using it you need to load assembly by calling a method, or creating an object belong MyAssembly.
There should be a Init method for the assembly to init things. you should call it.

Frame.Navigate to a Page-derived class in a different assembly

I'd like to keep my Windows Phone 8 Blank App template based view in a different assembly than the assembly containing the application manifest and App.xaml.
I keep receiving a cryptic exception which doesn't help at all in figuring out how to fix it:
Create a new project from the template Visual C# > Store Apps > Windows Phone Apps > Blank App (Windows Phone).
Build and deploy, works great. The properties of the MainPage.xaml state the Build Action is Page, which is correct.
Create a new project based on the Class Library (Windows Phone) template from the same category within the solution containing the original project, call it MyApp.Views.
Move the MainView.xaml file to the newly created project using Cut and Paste commands.
Add a reference to MyApp.Views to the original project.
Build, deploy, see the app start and fail to locate the view only to propagate this exception back to the developer's box: ComException: Error HRESULT E_FAIL has been returned from a call to a COM component. This doesn't say absolutely anything at all useful and the top stack frame is Windows.UI.Xaml.Controls.Frame.Navigate(Type sourcePageType, Object parameter) following the first one, which is TheOriginalProject.App.OnLaunched(LaunchActivatedEventArgs e).
The solution is not to use NavigationService with pack URI since it seems to be absent in Windows Phone 8, or at very least the assembly containing it is not referenced by default in the Blank App template. In any event, I'd vastly prefer strongly typed view names over pack URIs.
I imagine someone must've run into this issue already, what's the catch? Is there an API or a tool that will give me an insight on what the latest E_FAIL coming from COM is?
Edit: When using Window.Current.Content = new MainPage() as the only content of OnLaunched, the XAML parser exception pops up. It is unable to populate an exception message, but definitely gives a better hint to what's going on. Still no solution, though, the problem only moved to the this.InitializeComponent() in the MainPage constructor.
What I see now is Windows.UI.Xaml.Markup.XamlParseException with WinRT information of Parser internal error: Object writer '%0' and Additional information unable to load. x:Class attribute is present at the position 128 hinted on by the exception dialog window and this thread seems relevant, but I can't work out how.
Please note that I'll also find values in people confirming not receiving the error I do. If you've tried the steps to reproduce and failed to reproduce the problem, please write a comment so I can pin down what it is that causes the error I'm struggling with.

Alternative solution to externalizing views to a separate project while avoiding this problem is to use a Shared project project type, put the views there and reference it from the main project.
This does not produce a separate assembly for the views, instead the files are just grouped within their custom project, but behave as if they were part of the main project during compilation. The error goes away because from the compiler point of this, there's no difference between a file in a shared project and a file directly in the main project. During runtime, the type of the view doesn't need to be resolved from a different assembly, it's right there in the same assembly.

Strange exception suddenly appears when trying to install a setup project, need help big time

Using Visual Studio 2010 to build a setup project that installs a Windows Forms application .Net 4.0 C#. It has worked fine for ages but now when I'm trying to install the finished setup file, I'm getting this error message:
Error 1001. Unable to get installed types in the "Path" assembly. -->
Unable to load one or more of the requested types. Retrieve the
LoaderExceptions property for more information.
I have been searching for answers for over 4 hours now without finding anything. This problem just came without me doing anything. Last time I build the install file was like 2 weeks ago and there was NO problem at all. I haven't deleted any reference or any code that have anything to do with the setup project.
How could this problem appear from nothing and more important, how do I fix it?

Based on the error message in your second comment, it appears that your SysDir.exe assembly has been added as a Custom Action with the InstallerClass property set to true, but either no installer classes could be found in the exe or the exe could not be loaded due to missing dependencies.
You can see the list of Custom Actions by right-clicking on the installer project, selecting View and then Custom Actions.
If your exe does not can an installer class, then you can remove it from the list of custom actions.
If it does contain an installer class, then the issue is going to be missing dependencies. If fuslogvw doesn't work for you (it has always helped resolve this kind of issue for us), you can carefully review the list of references in the exe's project and compare them to what is listed in the installer project.
The other trick that we use is to examine the install directory while the error message is displayed on the screen. We can often see that DLLs are missing by doing this, usually because the path was entered incorrectly in the DLL entry within the installer project or because a condition was set incorrectly.

Have the same error today. For me it was the project type of the class library.
I noticed that the pucture on the guide I was following had selected Class Library (.NET Framework) instead of just Class Library.
Creating the correct project type fixed the error.
https://nhvu1988.com/posts/how-to-create-msi-installer-using-vs-installer/

C# DLL run-time error - builds, runs, but throws unhandled exception upon trying to use DLL functions

I am trying to compile the example project shown here for C#. It had to be converted to VS2010, but that worked fine. It builds, runs, but then dies when it tries to access a DLL function.
I made a series of images to show my steps. As you can see, the device I designed is attached and correctly configured, but I really don't think that has anything to do with the issue. Inside the Form1.cs file, the following comment explains how to use the DLL:
/*
PLEASE NOTE
You must add a reference to the FTChipIDNet.dll in order to use this sample
To do this:
1. Click on Solution explorer tab.
2. Right click the References tree.
3. Choose Add Reference option.
4. Browse to the FTChipIDNet.dll (as a personal preference I place this in my bin directory)
5. Click OK
*/
I followed the instructions shown above and the undefined reference to the namespace FTChipID was fixed. I also manually checked the Object Browser to be sure the GetNumDevices function exists and it does.
Clicking the button produces this error:
DLLNotFoundException was unhandled:
Unable to load DLL 'FTChipID.dll': The specified module could not be found. (Exception from HRESULT: 0x8007007E)
at this line of code:
FTChipID.ChipID.GetNumDevices(ref numDevices);
Now, you may be thinking "the error says it needs FTChipID.dll, not FTChipIDNet.dll." I'm wondering the same thing. I have FTChipID.dll along with a .lib and .h file, but I don't know how to use them or where they need to be in order for this program to find them. I tried adding a reference to FTChipID.dll, but VS2010 said
A reference to ...\FTChipID.dll could not be added. Please make sure that the file is accessible, and that it is a valid assembly or COM component.
I don't know what that means either. Any ideas? Thanks in advance.

FTChipIDNet.dll is a wrapper for the FTChipID.dll, so you need to add the reference to your solution (as you did above) and then copy the FTChipID.dll to the bin folder there FTChipIDNet.dll will be located.
Both dll's should be located in your solution's bin folder to operate and should not be located in windows\system32.

I built the FTDI sample program "CSChipID" in VS2013 using a build to "Any CPU". The two DLL files "FTChipID.dll" and "FTChipIDNet.dll" were copied to the bin directory, but I continued to get errors when the first DLL function was called, "FTChipID.ChipID.GetNumDevices(ref numDevices);" The fix is change the build to "x86" as follows.
Build - Configuration Manager
Active Solution Platform - "x86"
Note: If "x86" is not available, select -New...- to select "x86".

It sounds like there are multiple .dll's: both FTChipIDNet.dll (the one you interface to), and FTChipID.dll (the one with the actual, non-COM, non-.Net functionality). You need both.
SUGGESTION: Copy both to your \windows\system32 directory

Different location of assemblies stopped the type casting

I am writing a custom Control class in C# for my main project.
There're 2 projects, one for my Control and one for my main project. These 2 projects are in the same solution. I add a reference from my main project to my Control project. I notice that the first time after I drag my Control from the Tool Panel onto my main winform, an assembly folder was generated at the C:\Users\XXX\AppData\Local\Microsoft\VisualStudio\9.0\ProjectAssemblies, and the folder name is something like "jlebh-py01".
The first build is always OK, but after I rebuild my Control class or whole solution, a new assembly folder will be generated at C:\Users\XXX\AppData\Local\Microsoft\VisualStudio\9.0\ProjectAssemblies, and then problem arises, my Control fails to behave well because Visual Studio says that the two types "originates from different location". The error message is as below:
[A]MyControl.TypeXXX cannot be cast to
[B]MyControl.TypeXXX. Type A orginates
from assemblyXXX at location
'C:\Users\XXX\AppData\Local\Microsoft\VisualStudio\9.0\ProjectAssemblies\jlebh-py01\MyControl.dll'
Type B originats from assemblyXXX at
location
'C:\Users\XXX\AppData\Local\Microsoft\VisualStudio\9.0\ProjectAssemblies\ue4i-z3j01\MyControl.dll'
If I reference the Control DLL directly instead of through project reference, or never rebuild the Control project after use my Control in the main project, things seem to be OK.
Does anyone knows why? Is it the proper way to develop a control and a main project within the same solution?

From what you explained - it seems that the main project in your solution is not updating the reference to the control library that you have. I have been working in ASP.NET for a couple of years at least, and have had similar problems with referenced assemblies, but there was always a very simple fix to it - Rebuild the main project. This should clean it, and then run a fresh build.
Another thing you can try is add a variable assembly version to your control. In the project properties, assembly information, try set the version number to 1.0.* This will force the last two version numbers be based on the day and the time of the day, and each time you rebuild the control- it will have a different version. As long as the main project keeps the version updated - which it should - there shouldn't be any problems..