I'm working on IOS using Xamarin to restore some old android code. When trying to compile, there's a missing assembly error, pointing me towards this block of code:
[global::System.CodeDom.Compiler.GeneratedCodeAttribute("Microsoft.VisualStudio.Editors.SettingsDesigner.SettingsSingleFileGenerator", "11.0.0.0")]
internal sealed partial class Settings : global::System.Configuration.ApplicationSettingsBase
{...}
The error I get is as follow:
Error CS0234: The type or namespace name ApplicationSettingsBase does
not exist in the namespace System.Configuration. Are you missing an
assembly reference? (CS0234)
I get the feeling the problem lies within the "Microsoft.VisualStudio" part but I have no idea how to fix this.
Edit I see some people having similar problem being answered "Don't use Windows core dll". This might be the problem, but if it is I have no idea how to fix it.
I'm not sure how this could work on Xamarin.Android but System.Configuration (both the assembly and the namespace) are not part of the mobile profile that are shipped with Xamarin.iOS (and Xamarin.Android).
Also, more specifically to Xamarin.iOS, there's no code generation possible (no JIT is allowed by Apple) so it does not include namespaces (or types) from System.CodeDom.Compiler
Related
I have a problem using System.Device and can't find a solution
I'm developing a software and want to get the position of the device. By referencing the .NET Framework I want to use the GeoCoordinateWatcher.
In my code I included System.Device.Location and added two packages to the project (GeoCoordinate and System.Device.Location.Portable). While running and debugging the code in monodevelop no error occurs, but when I compile the code with mcs the error mentioned in the title occurs:
Namespace name "Device" does not exist in the namespace
Im using a RasPi for coding and compiling.
Any idea what the problem is?
System.Device is not supported by Mono:
https://github.com/mono/mono/tree/master/mcs/class
I'm attempting to use the following command line command to compile an assembly of the code from my project:
C:/"Program Files"/Unity/Editor/Data/Mono/bin/gmcs
-target:library -out:C:/Users/Austin/Desktop/PixelExpanse.dll
-recurse:C:/Users/Austin/Desktop/Projects/Repos/trunk/PixelExpanse/SpaceColonyRefactor/Assets/Source/*.cs
-d:RUNTIME -r:C:/"Program Files"/Unity/Editor/Data/Managed/UnityEngine.dll
As you can see, I am, I believe, correctly referencing the UnityEngine.dll.
The code that would be compiled contains references to UnityEngine.UI and UnityEngine.EventSystems. But when I run the above command, I get the following compile error:
error CS0234: The type or namespace name 'EventSystems' does not exist in the namespace 'UnityEngine'. Are you missing an assembly reference?
From what I have been able to find through googling, it SEEMS like an error people were getting when using a pre-4.6 assembly, because thats when EventSystems and UI were both introduced. But I don't know how I could be missing that in the dll I'm referencing as Unity 5 is the only version that has ever touched this computer.
As a side note, I have posted this question to Unity Answers and have yet to receive a response. I expect it's because assembly compilation is beyond the scope of what most users there choose to undertake. Hence my asking it here.
The namespace UnityEngine.EventSystems actually appears in UnityEngine.UI.dll and not UnityEngine.dll so it seems you need to reference the former too when compiling manually from the command-line. Unity projects have this by default (see below).
This is verified by opening up the assembly in your reflector tool of choice, here I am using JetBrains dotPeek:
This is how my test project appears with default Unity references. Note that by default a reference to UnityEngine.UI already appears in the Unity-created project:
When I built my Windnows desktop app via Unity, the above dlls appeared in:
<drive>:<projectOutFolder>\<projectName>_Data\Managed
You can try:
right click on "project panel", and after "Reimport All".
It's can be happen due to switch between platforms, e.g. IOS, or Desktop.. thus, folrders are deleted by became unecessary..
Solve for me: Unity 5.2, Win 7, 32bits;
Good luck!
I checked the UnityEngine.dll and the Eventsystems/UI namespace is not included. Despite, there is a dll in Unity5\Editor\Data\UnityExtensions\Unity\GUISystem\UnityEngine.UI.dll which includes these namespaces.
For mac, it's /Applications/Unity/Unity.app/Contents/UnityExtensions/Unity/GUISystem/UnityEngine.UI.dll.
Some background information:
I am using VS 2013
I created a Portable Class Library (Targets: .NET 4.5/Silverlight 5/Win Phone 8/Win Store 8)
I implemented the ICommand interface in my class named MyCommand.
MyCommand.cs:
public class MyCommand : ICommand
{
public bool CanExecute(object parameter)
{
throw new NotImplementedException();
}
public void Execute(object parameter)
{
throw new NotImplementedException();
}
public event EventHandler CanExecuteChanged;
}
I found that when I attempted to reference use the MyCommand class in a WPF 4.5 application, I get the following error:
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'.
I'm not really sure why this is happening, or what I can do to resolve it appropriately. After scouring the internet, I found answers talking about adding a reference to System.Windows.dll 4.0.0.0 in my WPF application. Doing this allows me to compile and run the application, but my IDE complains that:
Interface member 'void
System.Windows.Markup.IComponentConnector.Connect(in, object)' is not
implemented.
This occurs for my MainWindow.cs class. Is there a better fix than to just deal with this bug so I'm not adding a reference to System.Windows.dll in a WPF application which really doesn't need it? And I say that it doesn't really need it because if I copy/paste the MyCommand class into the Wpf app it works fine. It only has an issue because I am attempting to use it as a portable class library.
UPDATE:
It seems that there is more to this than meets the eye. I created a new Wpf Application and used NuGet to reference the MvvmCross solution (since it has an MvxCommand object). When I do this, I get the same error.
David Kean's answer to a similar question suggests that this should be fixed via VS2012/VS2013 and if not, just reinstall/repair. I fully removed my VS installation and reinstalled it from scratch (VS2013) and still have this issue. So, is this truly a bug or did I do something wrong here?
UPDATE 2:
I attempted to see if I could assign an instance of the MyCommand class to ICommand: ICommand cmd = new MyCommand(); and received the following error:
Cannot implicitly convert type 'PortableClassLibrary1.MyCommand' to
'System.Windows.Input.ICommand'. An explicit conversion exists (are
you missing a cast?)
For some reason the PCL does not seem to type forward the System.Windows.dll [2.0.5.0] ICommand to System.dll [4.0.0.0] ICommand for my desktop application... Ugh!
Update 3:
I uploaded my solution so that it is more visible as to what the problem is.
Update 4:
I've opened a Microsoft connect ticket on this issue.
Update 5:
After calming down from being upset about this not working... and others telling me that they don't get the same "interface" error. I realize that the "side-effect" of adding System.Windows.dll was a ReSharper 8.1 error. I guess it's time to complain to ReSharper instead of Microsoft. sigh
You must add a reference to assembly 'System.Windows, Version=2.0.5.0
The advice is excellent, the message is not that great. Clearly you got baffled by the version number. Right-click your WPF project, Add Reference and tick System.Windows. Which solves your problem.
The missing magic is this line in the System.Windows.dll reference assembly:
[assembly: TypeForwardedTo(typeof(ICommand))]
Which gets ICommand forward from System.Windows.dll to System.dll
Keep in mind that System.Windows.dll from the c:\program files (x86)\reference assemblies subdirectory is just a reference assembly. It doesn't contain any code or types at all, just [TypeForwardedTo] attributes. It acts as an "adapter", bridging the gap between different .NET framework platforms. The final executable doesn't actually have a dependency on System.Windows.dll at all.
This is not exactly a bug, it is more about what's included in the .NET Portable Subset. MSBuild is correct in complaining.
If you look at the manifest of PortableClassLibrary, you will see that an extern reference to System.Windows is actually made.
.assembly extern retargetable System.Windows
{
.publickeytoken = (7C EC 85 D7 BE A7 79 8E ) // |.....y.
.ver 2:0:5:0
}
And if you check what is actually contained in .NETPortable, you'll find that the included System assembly is v2.0.5.0
You can find it here -> C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETPortable\v4.0\Profile\Profile158\
...as is System.Windows at v2.0.5.0
So technically speaking, MSBuild is correct in asking for System.Windows, since this is not included explicitly in a build for WPF.
Although the TypeForwarding argument is interesting, it would still be moot, since at v2.0.5.0, there was no type forwarding to be done.
Now, if you actually look at System.Windows v4.0.0.0, there IS a TypeForwardedTo rule for ICommand (use reflector)
So the question here is more of a design issue, more than anything. System.Windows conflicts with WPF, yet this is only due to the other implementation of Window.
So to fix this, reference the v2.0.5.0 System.Windows in C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETPortable\v4.0\Profile\Profile158\System.Windows.dll (I would take a copy of it for this project).
Your last step is to resolve the type ambiguity that occurs because of this... you'll get a type ambiguity between System v4.0.0.0 and System.Windows v2.0.5.0 for the use of ICommand
You can solve this by removing System.Windows from the 'global' alias (hit F4 on the reference), and add in a custom alias, ex. SomeAlias
Then just reference it via it's alias.
extern alias SomeAlias;
public partial class MainWindow : Window
{
private SomeAlias::System.Windows.Input.ICommand _command;
...etc...
Voila.. this was really interesting, so I've detailed it a bit more here, where I could include screenshots (and talk about the ReSharper hiccup)
are you referencing System.dll?
ICommand
Supported in: Portable Class Library
No need to reference System.Windows.dll in your PCL, just add it in the WPF project.
Test solution
I'm building Windows Phone 8 app using MVVM Light. So far, so good.
However, when I used EventToCommand, I get multiple errors. One similar question is here EventToCommand not working when migrate to v4 for SL5, but sadly it doesn't solve my problem.! It automatically adds following reference:
xmlns:command1="http://www.galasoft.ch/mvvmlight"
Errors that I receive:
The name "EventToCommand" does not exist in the namespace "clr-namespace:GalaSoft.MvvmLight.Command;assembly=GalaSoft.MvvmLight.WP8"
The type 'command:EventToCommand' was not found. Verify that you are not missing an assembly reference and that all referenced assemblies have been built.
The tag 'EventToCommand' does not exist in XML namespace 'clr-namespace:GalaSoft.MvvmLight.Command;assembly=GalaSoft.MvvmLight.WP8'
Let me know if I'm missing anything or doing something wrong.
Thanks
Here is the correct xmlns (you were missing Extras in the assembly name):
xmlns:Command="clr-namespace:GalaSoft.MvvmLight.Command;assembly=GalaSoft.MvvmLight.Extras.WP8"
Replace it with
xmlns:command1="clr-namespace:GalaSoft.MvvmLight.Command;assembly=GalaSoft.MvvmLight.Extras.WP8"
With the recent version the command moved to Platform assembly:
xmlns:command="clr-namespace:GalaSoft.MvvmLight.Command;assembly=GalaSoft.MvvmLight.Platform"
I have a class library project that references another class library. The project fails to build and I get the error 'The type or namespace name 'ReportLibrary' does not exist in the namespace 'MSF' (are you missing an assembly reference?)'
The weird part is that I have other projects referencing the same class library that build fine. The only difference is that they are Windows Application projects. If I change the project type to a Windows Application and add a Program.cs with a [STAThread] and it builds.
So WTF? Anybody know what I'm doing wrong?
Edit (More Details): All projects in the solution are set to the same Target Framework: .NET Framework 3.5
EDIT (Unobfuscated the error message per Hans)
Is the class library (with the error) targeting the Client Profile, and the applications (as well as the reference library) targeting the full framework? If so, this could cause the reference to be invalid, and cause that message.