I have an Android app created in Xamarin.Forms (4.7.0) and I want to implement ads from AdMob into it. For that i have to create a ViewRenderer wrapper around a View class that I made earlier. As soon as i add this line into the ViewRenderer
[assembly: ExportRenderer(typeof(AdBanner), typeof(AdBanner_Droid))]
then build and launch the app, I get this error :
System.TypeLoadException: 'Could not load type DDKTCKE.Controls.AdBanner, APP_NAME, Version=1.2.2.0, Culture=neutral, PublicKeyToken=null while decoding custom attribute: (null)'
I already tried :
Deleteing bin and obj folders
Wiping data from test device
Cleaning the solution
A also used the exact same code in a new blank project and it worked as it should. What could be causing problems in my main project ? What should I look into ?
To implement the Android renderer, two classes are needed; an AdBanner class in the Forms project (or an Netstandard project as a project reference to the Forms project) and an AdBannerRenderer in an Android project:
AdBanner:
using Xamarin.Forms;
namespace MyProject
{
public class AdBanner: View
...
AdBannerRenderer:
using Android.Gms.Ads;
using Xamarin.Forms;
using Xamarin.Forms.Platform.Android;
using AdBanner = MyProject.AdBanner;
[assembly: ExportRenderer(typeof(AdBanner), typeof(Droid.Renderers.AdBannerRenderer))]
namespace Droid.Renderers
{
public class AdBannerRenderer : ViewRenderer<AdBanner, AdView>
...
I created a new project and copied all my code from my old solution into it. Now everything works flawlessly.
So once again this was a problem with VS that just popped up for no good reason and took me a week to find a f̶i̶x̶ workaround. And people wonder how anyone could hate Visual Studio.
Related
I tried to migrate an extension from Guide 6.7.3 to 6.8. Compilation did work without any changes, but the DLL is not loaded anymore.
It looks like the DLL is not even loaded, breakpoint in main constructor is not hit and Visual Studio claims that there are no symbols available.
Same version works correctly in Guide 6.7.3.
Stripped down minimal version which shows the problem:
using System;
using System.Collections.Generic;
using System.ComponentModel.Composition;
using System.Xml;
using Elektrobit.Guide.Studio.Workbench.ViewModels;
using Elektrobit.Guide.Ui.ViewModels;
using Elektrobit.Guide.Utilities;
[Export(typeof(IMenuItemProvider))]
public class TestMenuProvider : IMenuItemProvider
{
public string MenuId => "test";
[ImportingConstructor]
public TestMenuProvider()
{
}
public IEnumerable<IMenuItemViewModel> CreateMenuItems(object context)
{
return null;
}
}
Constructor TestMenuProvider() is run on 6.7.3 but not 6.8.
The example code works fine for me.
However, I stumpled upon a similar issue, so this might help you:
As they switched from x86 to x64 with version 6.8, I could imagine you may have missed to update the build settings of your extension project.
In the project properties of the Visual Studio project, head for Build -> Platform target and make sure it is set to x64 for all build configurations.
I've just upgraded from VS2013 to VS2015, and a ton of CS0436 warnings have appeared, all seemingly relating to the same issue.
I am slowly migrating web applications from VB to C#, so perhaps this is something really simple. I'm new to C# so please use layman-type answers...
My solution is structured as such:
Project 1 - Reusable methods (database access, etc)
\CommonDataAccessFunctionality.vb
Namespace MyCompany
Public Class CommonDataAccessFunctionality
Public Sub New(ByVal storedProcedureToRun As String)
' db stuff here '
End Sub
End Class
End Namespace
Project 2 - Web Applicable (C#) with dependency on Project 1
App_Code\DataAccess.cs
using System.Data;
using System.Data.SqlClient;
namespace QrCodes.App_Data
{
public abstract class QrDataCommon : MyCompany.CommonDataAccessFunctionality
{
public QrDataCommon(string storedProcedureToRun)
: base(storedProcedureToRun)
{
}
}
public class QrDataGrabber : QrDataCommon
{
public QrDataGrabber(string storedProcedureToRun)
: base(storedProcedureToRun)
{
}
}
}
The error is shown on this line:
public class QrDataGrabber : QrDataCommon
Warning CS0436
The type 'QrDataCommon' in 'D:\Web\wwwroot\MyApp\MyApp-InProgress-Person
WebApi\QrCodes\App_Code\DataAccess.cs' conflicts with the imported
type 'QrDataCommon' in 'QrCodes, Version=1.0.0.0, Culture=neutral,
PublicKeyToken=null'. Using the type defined in
'D:\Web\wwwroot\MyApp\MyApp-InProgress-Person
WebApi\QrCodes\App_Code\DataAccess.cs'.
I've read many posts on here about a project referencing itself, however, there are no references in the project dialog (that are listed), only a single dependency in Project 2 to Project 1. Also, Project 2 has no controls, etc, that reference anything else.
Can anyone please give me some guidance? I'm not sure if its helpful, but in the object browser when searching for 'QrDataCommon' I see this:
Update based on help so far
If I opt to view all files within Solution Explorer, within the \bin\ directory there is a file called QrCodes.dll that gets created when the project/solution is built. I also see the same in the hidden Debug folder.
If I rename the QrDataCommon class to something totally unique, say QrDataCommonTest123, and clean/rebuild, the error immediately updates to use the new class name.
Therefore, might this be something to do with the application build target location or something?
Warning CS0436
The type 'QrDataCommon' in '...DataAccess.cs' conflicts with the imported type 'QrDataCommon' in '...'. Using the type defined in '...DataAccess.cs'.
Most people likely run into this because of projects referencing themselves (as you pointed out); however, in your case it's because your VB project has a type with exactly the same namespace and name - a result of doing a direct 1:1 port from VB to C#.
Due to the name and namespace being identical C# has a choice to make: which one should it use? It is informing you that it is made the most logical choice and has chosen the one in your C# project - which is probably what you wanted it to do anyway.
These are your options:
Good option: Once you have completed porting a type to C# delete it from the VB project and recompile the VB project.
Good option: If you are not distributing your code as a standalone re-usable DLL (it looks like you are not), change the root namespace of your C# code.
Ignore the error until you have completed the port.
Worst option: Use a global namespace alias.
You have 2 DLLs using the same class name QrDataCommon. Rename one of them or don't reference QrCodes.dll.
The title suggest a easy problem.
But iam totally stuck at it.
I created a user control project to desgin my on control.
I build it and tested it.
It all works fine up to this part.
When i tried to add this control to my project visual studio told me that the type or namespace could not be found.
I got this error a few times before so i checked my references. But that was all fine.
So i created a test project added the control to that project and everything works fine.
I really don't know what the problem is.
Then i created a new usercontrol project used different namespaces and class names.
Because i thought that that would be the problem.
But the exact same thing happend.
In my test project it works fine. No reference error. But when i added it to my "main" project i got a reference error.
So if anyone could please help me out...
Here some code:
this is the class of the user control
namespace WET.Components.extendedCombobox
{
public partial class combobox: UserControl
{
//code
}
}
this line is added in the designer class.
the reference is added. but it cannot find the WET namespace
private WET.Components.extendedCombobox.combobox txtBedrijfsnaam;
Check build framework versions and assemblies. then check in the Errors and Output windows when adding the reference and compiling to see if there are any conflicts.
In my current personal project, I have a Core project, a DependencyResolution project, and a UI project (WPF application). In the UI project, I've tried to make a call to the DependencyRegistrar class that's in DependencyResolution in both MainWindow.xaml.cs and App.xaml.cs. There seems to be an issue with the UI project referencing the DependencyResolution project, as this compiler error always occurs:
The type or namespace name 'DependencyResolution' does not exist in the namespace
'DMTools.InitiativeTracker' (are you missing an assembly reference?)
D:\Dev\InitiativeTracker\src\UI\App.xaml.cs 2 33 UI
Just including the using statement anywhere in the UI yields that error.
using System.Windows;
using DMTools.InitiativeTracker.DependencyResolution;
namespace DMTools.InitiativeTracker.UI
{
public partial class App : Application
{ }
}
I can reference the Core project (using DMTools.InitiativeTracker.Core) and everything compiles okay. Furthermore, I can make references to DependencyRegistrar in the IntegrationTests project (another Class Library) and it compiles okay.
You can find the complete source here. Feel free to request specific snippets if you need more info.
EDIT:
I have added an assembly reference to DependencyRegistrar both via ReSharper and the typical Visual Studio way. Both cases did not resolve the issue. To the other comment: When I add a reference to a Core static class (IoC), the XAML remains unchanged but it compiles fine.
Tigran's comment figured out the mystery. In the UI project, I changed Target framework from ".NET Framework 4 Client Profile" to ".NET Framework 4" and it all works correctly.
The only thing I can think of as to why this was an issue with DependencyResolution and not Core is that the former makes references to third party utilities (i.e. Ninject) which has issues with Client Profile, but I'm only guessing here.
I'm getting this error
The type or namespace name 'DataVisualization' does not exist in the namespace 'System.Windows.Forms' (are you missing an assembly reference?)
Here is my using section of the class:
using System;
using System.Collections;
using System.Collections.Generic;
using System.Windows.Forms.DataVisualization.Charting;
using System.Windows.Forms.DataVisualization.Charting.Borders3D;
using System.Windows.Forms.DataVisualization.Charting.ChartTypes;
using System.Windows.Forms.DataVisualization.Charting.Data;
using System.Windows.Forms.DataVisualization.Charting.Formulas;
using System.Windows.Forms.DataVisualization.Charting.Utilities;
namespace myNamespace {
public class myClass {
// Usual class stuff
}
}
The thing is that I am using the same DataVisualization includes in another class. The only thing that I can think that is different is that the classes that are giving this missing namespace error are Solution Items rather than specific to a project. The projects reference them by link. Anyone have thoughts on what the problem is? I've installed the chart component, .Net 3.5 SP1, and the Chart Add-in for Visual Studio 2008.
UPDATE: I moved the items from Solution Items to be regular members of my project and I'm still seeing the same behavior.
UPDATE 2: Removing the items from the Solution Items and placing them under my project worked. Another project was still referencing the files which is why I didn't think it worked previously. I'm still curious, though, why I couldn't use the namespace when the classes were Solution Items but moving them underneath a project (with no modifications, mind you) instantly made them recognizable. :\
You are very likely missing a reference to the DataVisualization DLL. Note that although they share the namespace of System.Windows.Forms.dll, they aren't actually contained within it.
Solution items aren't used by compiled assemblies.
http://msdn.microsoft.com/en-us/library/1ee8zw5t.aspx
"They can be referenced by projects, but are never included in solution or project builds"
As far as I know, solution folders/items are really just meant for organizing things.
Are you getting actual build errors or just squiggles? Try building and look at the output window, does it succeed or fail?
In VS 2008 SP1 C# introduced a top level error squiggling feature. It's possible that if you open the solution item version of the file it will squiggle because of a lack of default references. The solution should still build correctly though.
If this is not the case try adding the file directly to the project (no link). See if that eliminates the error. If so then we know it has to due with a linked file and it can help track down the problem.