When i added a new from to my existing project, It shows this Warning Message
The type 'Banking_and_Financial_System.UserLoginForm' in 'D:\Internship
Project\Banking_and_Financial_System\Banking_and_Financial_System\UserLoginForm.cs'
conflicts with the imported type
'Banking_and_Financial_System.UserLoginForm' in 'D:\Internship
Project\Banking_and_Financial_System\Banking_and_Financial_System\bin\Debug\Banking_and_Financial_System.exe'.
Using the type defined in 'D:\Internship
Project\Banking_and_Financial_System\Banking_and_Financial_System\UserLoginForm.cs'.
in the Program.cs file on the Line below
Application.Run(new UserLoginForm());
Then I tried to modify the Existing form changed its name to Writeoff.cs then compiled it, I got the same above warning message.
This tells you that:
In UserLoginForm.cs, there is a type called Banking_and_Financial_System.UserLoginForm,
there is also a type calle Banking_and_Financial_System.UserLoginForm in Banking_and_Financial_System.exe
These two sound like the same thing to me, but it seems as if the latter of them is refering to a compiled version of your application. I find that a little strange, and I'm not sure about the technical details here, but it sounds like an accdidental inclusion causing a conflict.
Did you really mean to refer to the .exe-file in your debug-folder? If you've added such a reference explicitly, you should try to remove it.
Update:
Explanation: You can refer to and access public classes directly from a compiled .exe.
This has nothing to do with the file names of the forms and to do with the namespaces of the files.
You should specify the namespace for this call
Application.Run(new [insertcorrectnamespace].UserLoginForm());
What the error is telling you is it doesn't know which user login form you want to use as the class has knowledge of two with the same name but different namespaces
Related
I have two DLL files that have the same namespace but they have different methods and types.
How can I reference both DLLs in my project and use their methods and types?
By the way, these two DLLs have some methods and types with the same name but different implementation and some unique methods and types.
There's nothing special you need to do - just reference them and use the types. Namespaces can span accross several assemblies without problems, because they're not really opaque types. A namespace is just a way of adding a common prefix to all the types it contains, allowing you to have multiple types of the same name under different namespaces. (The framework doesn't see them as having the same names, because it sees the "fully qualified" name of everything - which has an alias and a namespace attached to the front of it.)
In the rare event that you reference 2 assemblies which have the same type names and the same namespaces (such as 2 different versions of the same dll) - you can distinguish which assembly to use for a given type using an alias. The default alias for all references is global, but you can specify your own alias for any assembly when you reference it (using a compiler switch - or just use the properties box in Visual Studio) - and have an extern alias <name> clause at the top of your code file where you use it - you would access the types from different assemblies with <name>::MyNamespace.Type
If you have 2 types with the exact same name (note that the name includes the namespace) but in different DLLs and you are interested in using both of them, then you can do this.
Short Answer
You have type Acme.Foo in 2 different DLLs and you want to use them. Give the reference an alias in the reference properties window (View | Properties Window) then use it like this:
extern alias TheAliasYouGaveTheReference
TheAliasYouGaveTheReference::Acme.Foo f = new
TheAliasYouGaveTheReference::Acme.Foo();
The default namespace is global for any C# program but note above we are using the alias we created instead of global.
The best approach is to NOT get into a situation like this in the first place, if both assemblies are your own, then do not create 2 types with the exact same name in the exact same namespace. But sometimes we do not control the source code so for those times, the above solution can be used.
Long Answer
I am copying most of the article from here so it is recorded here in case the article is no longer available.
How do you get into a situation like this?
Firstly, here is how you can replicate the scenario so it is really clear what we are talking about:
Create a C# Class Library called FooVersion1
Replace the template code in Class1.cs with the following:
using System;
namespace Acme
{
public class Foo
{
public void Bar()
{
Console.WriteLine("Bar");
}
}
}
Right-click on the solution in solution explorer and select Add | New Project
Save the current project (only applicable in express)
Select a Class Library in the new project dialog and change the project name to FooVersion2 and press OK
Replace the code in Class1.cs with the following:
using System;
namespace Acme
{
public class Foo
{
public void Bar()
{
Console.WriteLine("Bar");
}
public void Goo()
{
Console.WriteLine("Goo");
}
}
}
Usage of the type in Application
Ok so now we have 2 different assemblies containing Acme.Foo. Let's now create a console application and try to use each one.
Right-click on the solution in solution explorer and select Add | New Project
Select a Console Application and call it Consumer
Right-click on Consumer and select ‘Set as startup project’
Right-click on the references node in the Consumer project and select ‘Add Reference’
Click on the projects tab, and multi-select FooVersion1 and FooVersion2
Click OK
Add the following line to Main in the Program type of the Consumer project:
Acme.Foo f = new Acme.Foo();
Build the solution via Ctrl+Shift+B (or F6)
Notice that you get two build errors [as shown below]:
The Fix
Here is how we can fix it:
Open solution explorer and select FooVersion1 in the References folder of the Consumer project
Hit F4 (or select View | Properties Window)
Change the Aliases property to FooVersion1
Build the solution
Now everything will build correctly, because Acme.Foo unambiguously refers to FooVersion2
Add the following directive to the top of Program.cs in the Consumer project:
extern alias FooVersion1;
Change the usage of Acme.Foo to:
FooVersion1::Acme.Foo f = new FooVersion1::Acme.Foo();
f.Bar();
Notice that when you type ‘f.’ the completion list contains only those methods in FooVersion1 of Acme.Foo (notably it does not include Goo)
Build the solution and everything will build correctly
Finally add the following code under f.Bar() in Program.cs of the Consumer project:
Acme.Foo f2 = new Acme.Foo();
f2.Goo();
Notice that f2’s completion list contains Goo.
Build again using Ctrl+Shift+B and notice that there are still no build errors
you can use the alias feature of the /reference (Import Metadata) (C# Compiler Options) compiler option to solve your problems, read from here for more details
Here's the setup I'd like to have for my Windows Phone app, using c# in visual studio 2010:
**MainPage.xaml** contains elements that have an attached property, whose values will be modifiable/savable by the user.
**MainPage.xaml.cs**
first Namespace is PhoneApp ,inside it is a nested namespace called MyNamespace that declares the dependency property. it works(Thanks, Daniel)
**SettingsSample.xaml** that will allow users to change the values of the attached property in MainPage.xaml for any element and automatically save the change.
**AppSettings.cs** a class that exactly reproduces the first listing in this tutorial:
http://msdn.microsoft.com/en-us/library/windowsphone/develop/ff769510%28v=vs.105%29.aspx
That page declares the same NameSpace as the MainPage.xaml.cs (PhoneApp), then a public class called AppSettings that is exactly like in the tutorial.
To join everything together, I did:
**MainPage.xaml**
xmlns:local="clr-namespace:PhoneApp.MyNamespace"
I needed this to use the attached property
<phone:PhoneApplicationPage.Resources>
<local:AppSettings x:Key="appSettings"></local:AppSettings>
</phone:PhoneApplicationPage.Resources>
Confusion begins. On the tutorial, they put this on the settings page, but I guess because their settings page is also the one including the elements with the properties that are bound to the saved settings. Mine are on the mainpage, so I put this here. To recap, My settings page will only use methods to change/save these values(and the methods are in AppSettings.cs). Also in the tutorial they add this:
xmlns:local="clr-namespace:SettingsSample"
to the Setting Page(where "SettingsSample" is the Namespace containing declaration/get-Set methods of savable settings) but, for the same reason, I tried to put it on the mainpage, but only one declaration of xmlns:local can be done. I tried several things to put them one after the other, but it doesn't work. This is the key to the two errors I'll list below.
Some elements of mainpage have this, for exemple:
local:MyClass.Son="{Binding Source={StaticResource appSettings}, Path=son1, Mode=TwoWay}" Style="{StaticResource pad}"
"Son" is the attached property
Ok, so I tried different different things but it never worked. The best I could get was in MainPage.xaml that it couldn't create an instance of AppSettings. Now it's different, I have the two errors.
-the type local:AppSettings was not found
-the tag AppSettings does not exist in xml namespace PhoneApp.MyNamespace.
I think this is because I didn't put the
xmlns:local="clr-namespace:PhoneApp"
But I already have
xmlns:local="clr-namespace:PhoneApp.MyNamespace"
and can't put both.(and to me, one is included in the other...) The reason I listed all the ins and out of the situation is because I kind of expect other troubles after I get through this.
I hope this message is clear enough for someone to help me. I spent so much time on it that I begin to loose my mind, so I hope there's no stupid mistake. Of course, I can add any information needed. Thank you for reading anyway!
These are XML namespace mappings. With the following:
xmlns:local="clr-namespace:PhoneApp"
The local part is the XML namespace, whilst PhoneApp is the namespace from your .NET code. With this definition in place you can then reference classes from this namespace in XML as follows:
<local:MyClassInPhoneAppNamespace/>
Because the local part is simply a name, you can change it to whatever you like:
xmlns:fish="clr-namespace:PhoneApp"
And use as follows:
<fish:MyClassInPhoneAppNamespace/>
This should mean that you no longer have collisions.
"local" in this case is simply a friendly name for the namespace you are referencing. It is completely interchangeable.
I was in need to import two local in same file as below
xmlns:local="clr-namespace:Generique.Views.Assets.Entries"
xmlns:local="clr-namespace:Generique.Views.Assets"
I just change the name and it works fine
xmlns:local="clr-namespace:Generique.Views.Assets.Entries"
xmlns:footer="clr-namespace:Generique.Views.Assets"
I am trying to add my own namespace to my xaml file in order to use my own class easily -I guess the reason is this-
I wrote the following code in window tag for this:
xmlns:myns="clr-namespace:LibNameSpace"
Where my window tag also starts with the following definition:
<Window x:Class="LibNameSpace.MainWindow"
I want to use the LibNameSpace:Class1 class, and I was hoping to write myns:Class1 for this. However, that command causes this error:
Undefined CLR namespace. The 'clr-namespace' URI refers to a namespace 'LibNameSpace' that is not included in the assembly.
How can I fix this?
The name LibNameSpace sounds like its a library in another assembly. If this is the case, you must add the name of the assembly:
xmlns:myns="clr-namespace:LibNameSpace;assembly=MyLibAssembly
Update:
The name of the assembly can be found in project-explorer in the properties-screen of the project (of the library-assembly). In general also the file-name of the dll without the dll-suffix represents the assembly name.
Because for me it's not really clear what you want to do, here another try:
If MyLibAssembly is the main namespace of your application and there in you have a Window named MainWindow and a class named Class1 that you want to instantiate in your MainWindow-class:
Make sure, that in Class1 is no
error, the project must
compile without errors. Remove first the
namespace-declaration from the xaml and compile your
project till you have no compilation errors.
Make sure that Class1 is public and
has a paramterless constructor
Make sure that in the code behind
your MainWindow is also in the
MyLibAssembly-namcespace.
Add then the namspace-declaration
xmlns:local="clr-namespace:LibNameSpace
into your xaml. local is generally
used to declare the same namespace as your current element, in your case the window, is in.
Insert your Class1 with the
<local:Class1/> -tag in the xaml. If Class1 does not derive from FrameworkElement or a higher level control, you must add it into the resources-section of your window. If this is true, give it a key. <local:Class1 x:Key="KeyToYourClass"/>
Maybe vs is out of sync. Click in the solution-explorer on the root-node Clean Solution and then Rebuild Solution. Maybe that helps.
I hope this helped. If not, try to reformat your question (use the code-symbol to make the question more readable and try to rephrase to make more clear what your desire is).
Use Intellisense. In my case one space mattered. instead of
xmlns:local="clr-namespace:DataAccess;assembly=DataAccess"
I hand typed
xmlns:local="clr-namespace:DataAccess; assembly=DataAccess"
Notice the space after ';'. This made the difference. So use visual studio Intellisense and it will render you correct xaml markup.
I found this answer while I was struggling with problems in Windows 8. I was trying to use a User Control and I had several errors. The last ones where:
Error 9 Cannot add 'ScrollControl' into the collection property 'Children', type must be 'UIElement'
and:
Error 10 Unknown type 'ScrollControl' in XML namespace 'clr-namespace:EventTests.Controls;assembly=EventTests, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null'
ScrollControl is my user control.
I ended up replacing this:
xmlns:Controls="clr-namespace:EventTests.Controls"
For this:
xmlns:Controls="using:EventTests.Controls"
I hope this saves the time I spent with this issue.
In my persistence layer, I've declared a load of Enums to represent tables containing reference data (i.e. data never changes).
In Linq2SQL, I am able to set the type of an entity property to an enum type and all is well, but as soon as I set a second entity's property to use the same enum type, the Code Generator (MSLinqToSQLGenerator) start generating an empty code file.
I assume that MSLinqToSQLGenerator is quietly crashing. The question is why, and are there any work-arounds? Anyone else experienced this problem?
Is your enum by any chance in a file named the same as the dbml? There is a bug in 3.5 (fixed in 4.0) where conflicts cause an empty file. Oddly, usually moving the using directives (and right-click; run custom tool) fixes it.
So if you have "foo.dbml" and your own "foo.cs" (in the same folder) with:
using System;
namespace MyNamespace {
}
it will break (generate an empty foo.designer.cs). If you have:
namespace MyNamespace {
using System;
}
it will work. I'm not kidding. Likewise, renaming "foo.cs" to "bar.cs" (and right-click, run custom tool) will fix it.
Oddly, I've discovered that this behavior only occured with an Enum named "GrantType". As soon as changed the name of the enum, the generator started working again.
Basically what I'm hoping for is something that would work like how the Obsolete attribute works with Intellisense and strikes the method text when typing out the name. What I'm looking for is an attribute that blocks the method from being seen with the assembly it's defined. Kind of like an reverse internal. Using 3.5 by the by.
Yeah sounds odd but if you need the reason why, here it is:
My current solution for lazy loading in entity framework involves having the generated many to one or one to one properties be internal and have a facade? property that is public and basically loads the internal property's value:
public ChatRoom ParentRoom
{
get
{
if(!ParentRoomInnerReference.IsLoaded)
{
ParentRoomInnerReference.Load();
}
return ParentRoomInner;
}
set
{
ParentRoomInner = value;
}
}
Problem with this is if someone tries to use the ParentRoom property in a query:
context.ChatItem.Where(item => item.ParentRoom.Id = someId)
This will blow up since it doesn't know what to do with the facade property when evaluating the expression. This isn't a huge problem since the ParentRoomInner property can be used and queries are only in the entity assembly. (IE no selects and such in the UI assembly) The only situation comes in the entity assembly since it can see both properties and it's possible that someone might forget and use the above query and blow up at runtime.
So it would be nice if there were an attribute or some way to stop the entity assembly from seeing (ie blocked by intellisense) the outward facing properties.
Basically inside the assembly see ParentRoomInner. Outside the assembly see ParentRoom. Going to guess this isn't possible but worth a try.
I do see that there is an attribute
for stopping methods from being
viewable
(System.ComponentModel.EditorBrowsable)
but it's choices are rather slim and
don't really help.
You can use the EditorBrowsableAttribute for this:
[System.ComponentModel.EditorBrowsable(System.ComponentModel.EditorBrowsableState.Never)]
public void MyMethod() {}
One thing to know, though: In c#, you will still get intellisense on the method if it is in the same assembly as the one you are working in. Someone referencing your assembly (or your project, for a project reference) will not see it though. You can also pass EditorBrowsableState.Advanced, and then you will only get intellisense if c# if you clear the HideAdvancedMembers option in Tools Options.
I haven't heard of a good way to do this in plain .NET. But, here are some ideas. Maybe one of them will work, or set you off in a direction that will be helpful.
Use FxCop, probably writing your own rule to make sure ParentRoom isn't called from the asslembly that defined it.
Look into the various post-processing projects for .NET (link design-by-contract).
Write some code inside your ParentRoom getter which will check the stack (using "new Stack()" or "new StackFrame(1)" to figure out whether the caller was from the same assembly. If so, either throw an exception or simply return ParentRoomInner.