I am using Portable Class Libraries (PCL) in Xamarin Studio on OS X. I have two PCL libraries that are targeting .NET 4.5, Windows Phone 8, Windows Store Apps, Xamarin.iOS, and Xamarin.Android. I reference these two libraries in my iOS, Android, and Unit tests projects. In 3 areas I am getting the following error:
The type 'System.Object' is defined in an assembly that is not referenced. You must add a reference to assembly 'System.Runtime, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'.
The code is straightforward:
MyClass myClass = new MyClass();
The error occurs once in each of the projects that reference the PCLs. None of them are the same class. I am new to PCLs. I've tried removing the Windows Phone 8 (as I added it last minute) and yet the problem does not go away. Any help would be appeciated!
Thanks!
Update:
So this occurs with the first field declared in the class (where the class is from the PCL project).
int a = 0;
MyPCLClass _myPCLClass = new MyPCLClass(); //This is where the error appears
Another odd aspect is that there are over 50 classes using these classes, and the error is only appearing in three classes.
I just ran into this exact same problem, and have the same setup as you do. A tip mentioned in a comment (by Stuart, which in turn mentioned a tweet by #DavKean) to this question solved it for me.
You have to:
access a Windows machine (I used a Windows 8)
grab C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.5\Facades\System.Runtime.dll
copy it to your Mac
add a reference to this dll from each of your iOS and Droid projects
Which version of Xamarin.Android and Xamarin.iOS are you using? You need to be using of the Xamarin.Android 4.7.x alphas for PCL support, or the forthcoming 4.8 release. (Ditto for Xamarin.iOS: you need a pending future release for PCL support, or use the alpha channel.)
Related
I am trying to import VB6's VBRUN type library into a Visual C++ 2017 header file, but it is failing due to a missing dependency.
Visual C++ reports
"error C4772: #import referenced a type from a missing type library;
'missing_type' used as a placeholder"
Viewing the file with OLE View reveals the problem is with the DataFormat property (DataFormat([out, retval] --<GetRefTypeInfo failed>** Return)).
The missing dependency would appear to be stdDataFormat: which type library does stdDataFormat reside in and why is it missing? (My operating system is Windows 10 Enterprise, 21H1.) Did I miss a selection when installing Visual Studio 6?
This addresses the first part of the question, how to find the typelib (TLB) containing a given interface or class.
Assuming you have no preconception about the TLB / DLL hosting a given COM interface or class you can find it by a couple of registry searches, assuming the type in question actually has been registered.
I started off in HKEY_CLASSES_ROOT with a search for data values = stdDataFormat. This lead to:
[HKEY_CLASSES_ROOT\MSSTDFMT.StdDataFormat]
#="StdDataFormat Object"
[HKEY_CLASSES_ROOT\MSSTDFMT.StdDataFormat\CLSID]
#="{6D835690-900B-11D0-9484-00A0C91110ED}"
Now armed with the CLSID GUID of 6D835690-900B-11D0-9484-00A0C91110ED, search for that value, finding:
HKEY_CLASSES_ROOT\WOW6432Node\CLSID\{6D835690-900B-11D0-9484-00A0C91110ED
of which its important sub-element for our purposes is:
[HKEY_CLASSES_ROOT\WOW6432Node\CLSID\{6D835690-900B-11D0-9484-00A0C91110ED}\InprocServer32]
#="c:\\windows\\SysWow64\\msstdfmt.dll"
...
The InprocServer32 value was the main thing I wanted to find; it tells you the DLL - which is c:\windows\SysWow64\msstdfmt.dll (on my PC - but this should be typical).
Opening msstdfmt.dll in OLEView (or OLEViewDotNet) confirms this; the decompiled IDL from the TLB in that DLL contains:
[
uuid(6D835690-900B-11D0-9484-00A0C91110ED),
helpstring("StdDataFormat Object"),
helpcontext(0x00066b5f)
]
coclass StdDataFormat {
[default] interface IStdDataFormatDisp;
[default, source] dispinterface IStdDataFormatEvents;
};
So msstdfmt.dll should be the missing dependency.
If you did suspect this DLL to begin with, then obviously its a lot quicker to just load it in OLEView and check. But in many cases that won't be obvious when you're starting out.
As for the second part of the question - why is this dependency missing - maybe it would help if you added the relevant section of your code / includes?
I have a project that I'm trying to get updated to the universal CRT, and I'm still seeing a dependency on vcruntime140.dll and msvcp140.dll, which I think should have been replaced with a ucrtbase.dll, as well as api-ms-win-crt* dlls.
I've already checked out this response here, and this blog post, which explain things pretty well, but still no luck. Here's what I've changed:
Platform Toolset: Visual Studio 2019 (v142)
Windows SDK version: 10.0 (latest installed version)
Additional include directories: added $(UniversalCRT_IncludePath)
Additional library directories: added $(UniversalCRT_LibraryPath_x86)
I also updated my linker dependencies to this set:
ucrt.lib
vcruntime.lib
msvcrt.lib
user32.lib
advapi32.lib
Wsock32.lib
Crypt32.lib
ws2_32.lib
But when I run dumpbin /dependents mydll.dll
File Type: DLL
Image has the following dependencies:
api-ms-win-crt-string-l1-1-0.dll
api-ms-win-crt-heap-l1-1-0.dll
api-ms-win-crt-runtime-l1-1-0.dll
api-ms-win-crt-stdio-l1-1-0.dll
api-ms-win-crt-filesystem-l1-1-0.dll
api-ms-win-crt-convert-l1-1-0.dll
api-ms-win-crt-time-l1-1-0.dll
api-ms-win-crt-environment-l1-1-0.dll
api-ms-win-crt-utility-l1-1-0.dll
VCRUNTIME140.dll
USER32.dll
ADVAPI32.dll
WSOCK32.dll
CRYPT32.dll
WS2_32.dll
MSVCP140.dll
bcrypt.dll
KERNEL32.dll
Summary
E000 .data
66000 .rdata
E000 .reloc
1000 .rsrc
14A000 .text
Is there something else I'm missing to be able to drop the dependency on the specific CRT version?
I've done some more digging, and found this page that says the following:
Starting in Visual Studio 2015, the CRT has been refactored into new
binaries. The Universal CRT (UCRT) contains the functions and globals
exported by the standard C99 CRT library. The UCRT is now a Windows
component, and ships as part of Windows 10.
Great, that's what I expected. Just below though is this:
The vcruntime library contains Visual C++ CRT implementation-specific
code, such as exception handling and debugging support, runtime checks
and type information, implementation details and certain extended
library functions. This library is specific to the version of the
compiler used.
Which implies that there is still a non-universal VC++ dependency that gets linked in by VS. To me, this implies that a dependency-free DLL doesn't really exist (at least not something built with VC++), since you'll always have a vcruntime dependency.
There is always the option of static linking (/MT), but in my case, I'm also looking at a DLL that has /clr, and the two options are mutually exclusive. Application local deployment (just copy vcruntime140.dll with the binaries) also seems to work, and may be the best option for something that I want to be a portable/xcopy deployment.
I'm going to mark this as an answer for now, but if there's a way around this, I'd be interested in seeing it.
As suggested in this post, If I install the VC++ redistributables for VS2015 update 3 am I likely to break other software running on the same PC built with previous updates to VS2015? Similarly, if I stick with update 2 for my release, is this going to get broken at some point in the future when someone installs the redists for update 3?
Based on the bug description as reported at New VC Runtime 14.0.24210.0 breaks MFC app built with VS 2015 Update 2 the U3 redistributables will indeed break MFC apps compiled with U2 or earlier, which:
use MFC in a DLL i.e. not statically linked, and
create objects of type CMFCToolBarButton or derived.
From the linked page:
The problem is caused by the new BOOL member m_bIsDragged in class CMFCToolBarButton.
So memory layout differs between Update 2 and 3.
When initializing m_bIsDragged in the constructor, the (stack) memory behind the ToolBarButton is overwritten.
The problem should arise also on all classes which are derived from CMFCToolBarButton:
CMFCColorMenuButton
CMFCCustomizeMenuButton
CMFCDropDownToolbarButton
CMFCOutlookBarPaneButton
CMFCRibbonGalleryMenuButton
CMFCToolBarComboBoxButton
CMFCToolBarDateTimeCtrl
CMFCToolBarEditBoxButton
CMFCToolBarFontComboBox
CMFCToolBarFontSizeComboBox
CMFCToolBarMenuButton
CMFCToolBarMenuButtonsButton
CMFCToolBarSpinEditBoxButton
CMFCToolBarSystemMenuButton
[ EDIT ] For completeness, it should be pointed out that apps that use AppLocal deployment of the MFC/CRT DLLs are not affected, since they do not use the system-wide installed copies thereof.
AppLocal deployment is described under bullet #6 "updated September 11 2015" in "Distributing Software that uses the Universal CRT" at Introducing the Universal CRT.
So I recently got Visual Studio 2012. I converted a Visual Studio 2010 solution to a Visual Studio 2012 project. It was working before I converted it.
I have this line of code:
this->Text = global::ProjectName + " (" + global::Type.ToString() + ") - Path Creator 2.0";
where global::Type is:
ref class global {
public:
static Rct3PathType Type;
...
};
...and Rct3PathType is:
enum class Rct3PathType {
Basic = 0x02060206,
Extended = 0x05060506,
Queue = 0x01070107
};
I get an error at compile time where ever I have called global::Type.ToString() saying "error C2228: left of '.ToString' must have class/struct/union". Considering this all compiled completely well BEFORE switching to Visual Studio 2012, I'm not sure what the issue is! :(
Also, when I try to run the last successful build (which was built with Visual Studio 2010), I get runtime error at startup saying "The program can't start becayse MSVCR100D.dll is missing from your computer." I know this probably doesn't relate to the issue at hand, but does anyone know why this may be happening as well?
Thanks for your help,
Alex
"error C2228: left of '.ToString' must have class/struct/union": enum class is also the syntax for a C++11 enum. To make it a C++/CLI enum, give it an accessibility specifier, which is not allowed on a C++11 enum. In other words, private enum class or public enum class will change it from a C++11 enum to a C++/CLI enum. This wasn't a problem in VS2010 because it doesn't support C++11 enums.
"The program can't start because MSVCR100D.dll is missing from your computer.": VS2012 uses a different C runtime than VS2010. MSVCR100D is the Microsoft Visual C Runtime version 10.0, Debug version. This DLL is installed with VS2010, there is no other way to get it. If you have an old Release build, you can get the runtime redistributable from Microsoft (x86 or x64), and install that to make it run. (That will be MSVCR100.dll, no "D" at the end.)
I am using MonoDevelop 2.2 from the Debian testing repository. I have installed the addins for GTK support, for version 2.8 and 2.10.
When I compile my solution, I get warnings saying Warning: Assembly 'glade-sharp, Version=2.10.0.0, Culture=neutral, PublicKeyToken=35e10195dab3c99f' not found. Make sure that the assembly exists in disk. If the reference is required to build the project you may get compilation errors. (ProCos)
The warning is perfectly alright, because the installed libraries do not offer V2.10 of glade-sharp. So I open the reference dialog, remove the reference and insert a reference to V2.8 of glade-sharp (which does exist). Close the reference dialog and recompile. And bang, same warning and the reference has been changed back to V2.10.
Anybody have any ideas how to fix this? Or is this a known bug in that version of MonoDevelop?
If you're using the GTK version support, all the GTK-related assemblies should have the same version. I suspect that if gtk-sharp.dll is 2.10, then MD will "fix" glade-sharp to 2.10 too. In project options is a dropdown for picking the GTK version; using this will update all GTK assemblies to a specific version.
Note also that you can use the project pad to set a reference to not require a specific version.
I suggest trying MD 2.4, and if it's still an issue, please file a bug report.