in Visual Studio 2017 I have a solution with aspnet core project and about 10 net core libraries referenced to each other.
One of the libraries is xUnit test project. It referenced to another project it should use as aim for testing.
For example I have:
Project: MyProject.Domain
Test Project: MyProject.Domain.Tests
MyProject.Domain.Tests is referenced to MyProject.Domain.
In these projects I have classes with namespaces like project names.
So the strange thing happened when I can use public class from MyProject.Domain WITHOUT using MyProject.Domain.
Can anybody explain it ?
If I understand you correctly, you're wondering why a type in the namespace MyProject.Domain.Tests can access types in the namespace MyProject.Domain without any usings. The reason for that is that the specification says so. From Namespace and type names (edited by removing irrelevant parts):
The meaning of a namespace_or_type_name is determined as follows:
If the namespace_or_type_name is of the form I:
For each namespace N, starting with the namespace in which the namespace_or_type_name
occurs, continuing with each enclosing namespace (if any), and ending
with the global namespace, the following steps are evaluated until an
entity is located:
If N contains an accessible type having name I, then:
The namespace_or_type_name refers to the type.
Related
Good day,
I have used dll imports for "user32.dll" in the past.
However, I am trying to import a class library into my application which has some namespaces which come into conflict with namespaces which are already imported and referenced from other class libraries.
How can I reference this dll and only use the namespaces contained in it, or override the other namespaces imported from other class libraries in one class without it affecting the rest of the application.
I am still pretty new, this may not be possible.
Thank you.
To summarize the relevant issues:
In VB.NET one can use the Declare statement to call win32 functions in DLL's with typical EntryPoint constructs.
.NET Assemblies do not provide classical Win32 type EntryPoints (as such they cannot be 'declared')
If one needs to reference a .NET Assembly [or COM] you need to add a reference to the target library when compiling (usually done in the VS IDE or with the /r: switch)
In some cases Namespaces of such referenced Assemblies may collide with others. (i.E. referencing the same Assembly in different versions)
In that case one needs to import the required (conflicting) Namespaces with an Alias
For example:
Assuming you have an assembly with a root namespace Net that could collide with System.Net use:
Imports System
Imports ExtNet = SomeNetworkAssembly
Then in this case to access members of that assembly use ExtNet instead of Net
Note you can name the ExtNet part as you wish.
In C# one can do it via the using keyword instead.
I created a new Metro Split App in C++ using VS2012 on Win8 (both RC). Everything compiled and worked out of the box. I then changed went through and changed the generated namespaces to my own. After some trials and tribulations, I got everything to compile with no warnings, errors, nor messages. The app (as it comes in the project template) runs fine.
However, if I try to edit either of the generated xaml files (ItemsPage.xaml or SplitPage.xaml) I get a "Markup error" on the first line:
The name "LayoutAwarePage" does not exist in the namespace "using:A.B.Product.Client.Common".
The definition of the class is:
namespace A{ namespace B { namespace Product { namespace Client { namespace Common
The code compiles fine, and runs fine. This only happens in design mode.
UPDATE: I added a new xaml file and (after fixing up the namespaces again) everything worked.
Please let me know if any additional information is needed.
The name of the WinMD file produced by your project must be some prefix of the namespaces in which the public WinRT types are defined. Given that your type is in the A.B.Product.Client.Common namespace , the WinMD file must have one of the following names:
A.winmd
A.B.winmd
A.B.Product.winmd
A.B.Product.Client.winmd
A.B.Product.Client.Common.winmd
The public types must also be defined in the WinMD file with the longest prefix that matches the namespace. So, if you have both A.winmd and A.B.winmd, the type A.B.MyClass must be defined in A.B.winmd.
So, why does your code work at runtime but not in the designer? The naming rules for public types only apply to types defined in Windows Runtime components (for C++, DLL files), not for applications (EXEs).
However, to be able to instantiate your user-defined types (including LayoutAwarePage), the designer will load your project's EXE as a DLL, so the naming rules must be followed.
I had a similar bug, but then I closed VS, deleted the .suo, and reloaded the project and everything worked just fine.
MVC 4 Beta project fails to compile after upgrading to .Net 4.5.
This happens due to conflict between
System.ComponentModel.DataAnnotations.CompareAttribute and System.Web.Mvc.CompareAttribute
System.ComponentModel.DataAnnotations.CompareAttribute MSDN documentation says:
Provides an attribute that compares two properties.
While System.Web.Mvc.CompareAttribute MSDN documentation says:
Provides an attribute that compares two properties of a model.
What is the difference between the two and when it would be "smarter" to use each of them?
10x.
So, looking at the MSDN documentation and doing a literal comparison of the two classes, I noticed both classes are derived from System.ComponentModel.DataAnnotations.ValidationAttribute. In fact, the classes are almost exactly the same. The only notable difference is that the MVC version also implements IClientValidatable which adds the following properties:
FormatPropertyForClientValidation - (static member) Formats the property for client validation by prepending an asterisk and a dot.
GetClientValidationRules - Gets a list of compare-value client validation rules for the property using the specified model metadata and controller context.
As for which class you should use, if the model will be directly bound to a view, use the MVC version so that you can take advantage of the client-side validation. However, if you're using ViewModels, you can stick with the ComponentModel class and avoid the unnecessary overhead of the additional properties. Your call!
System.Web.Mvc.CompareAttribute
System.ComponentModel.DataAnnotations.CompareAttribute
Microsoft Connect work-around is:
Posted by GavK on 6/17/2012 at 5:13 AM
I added a full reference to [System.Web.Mvc.Compare(...)] rather than
just using [Compare(...)]
Works for me in VS 2012...
Vinney nailed most of it with the exception of which one you should use...
The reason you have a conflict after changing your target framework to 4.5 is because prior to .NET 4.5 there was no CompareAttribute class in the System.ComponentModel.DataAnnotations namespace and the class defined under System.Web.Mvc filled the gap. Therefore, as an example if you were using [Compare] and [Required] attributes in your model class prior to updating your target framework you ended up with a conflict when you upgraded.
Assuming you are not using anything else in the System.Web.Mvc namespace in your model class, you should remove that using statement and let it rely on the System.ComponentModel.DataAnnotations namespace. Unobtrusive client-side validation will continue to work exactly as it did before, just as it does for other attributes that you decorate your model's properties with from the same namespace (eg Required).
If you wish to be explicit about the reference, you can simply add this line:
using CompareAttribute = System.Web.Mvc.CompareAttribute;
Using Visual Studio 2013 (MVC 5 project, .NET 4.5) the IntelliSense suggests that System.Web.Mvc.CompareAttribute is deprecated.
I used System.ComponentModel.DataAnnotations.CompareAttribute and it works fine.
It also does the client-side validation!
On this post, they also suggest another solution, which is to move the reference of the preferred namespace for Compare() inside the model's namespace. Eg. if you prefer to use Compare from System.Web.Mvc, use:
using System.ComponentModel.DataAnnotations;
namespace MyProject.MyViewModel
{
using System.Web.Mvc;
The compiler will search inside the model's namespace first.
I've googled for creation of namespaces and found some very useful examples, what these examples didn't have is how do I compile and implement my created namespace on my system so I can include it from my various applications.
So for example, if I create a namespace to load a config file from my application path and insert it to an array, Do i need to include the namespace on any project I use or is there a way to make it part of my environment?
You're thinking of Class Library (DLL) projects.
When you start up a new Visual Studio project, select Class Library rather than Windows Form project. This will compile your namespaces as a DLL (exposing your public classes), which can be referenced in other projects.
If you want to include a namespace that you created you have to add a reference to your project first. If you have compiled your code into a .dll file, then simply add the reference to the .dll file to your project and then at the top of your classes put the "Imports [Namespace]". If you haven't compiled your namespace, add the project (with the namespace that you created) to your solution, add the reference to it (under the Projects tab), and then use the Imports statement.
You are confusing the concept of a namespace with the concept of a project, especially of a class library project.
A class exists within a namespace. If no namespace is defined, then the class still exists within the global namespace (the one with no name).
In any case, it's classes that do the work. Namespaces are only so that you can have a class named Book, and I can have a class named Book, and so that TriDat.Book can exist at the same time as JohnSaunders.Book.
I'm getting a compiler error saying that "Acme.Business.User" is not defined.
I have a class library project called "Acme.Business" that has "Acme.Business" as the assembly name and root namespace as well. None of the classes use the "Namespace" keyword, so they all should exist in the namespace "Acme.Business".
I also have a class library project called "Acme.Web" that has a project reference to "Acme.Business". Again "Acme.Web" is the project name, assembly name, and root namespace.
Here's the weird part. If I add a class to "Acme.Web" I can type "Imports Acme." at the top and see both namespaces appear in intellisense like you'd expect, but if I try to do "Dim x as New Acme.Business.User" then "Business" doesn't show up in intellisense and I get an error saying "Acme.Business.User" is not defined.
I can't see what I'm doing wrong! Please help. Thanks.
I think you may be misunderstanding how project default namespaces work. The default namespace is a project file setting that simply tells Visual Studio what namespace to add to each file when you add a new class file to the project. If you have removed all of these namespaces from the code files then your types do not exist in that namespace.
This means that all of your types in the Acme.Business assembly live in the global namespace which is probably not what you want. In order to get the desired behavior you will need to add the namespaces back into your code files as that is the only way the compiler will create type names with that namespace.
OK, I figured out that the behavior I was seeing was because I was declaring namespaces within the code in Acme.Web the way I was used to in C# which is to fully qualify it, ie. Namespace Acme.Web.UI.WebControls. I didn't realize that in VB.NET it's building on top of what was specified for the root namespace. I removed the portion that was specified in the "root namespace" setting of my project and it started working. So my namespaces in code for Acme.Web now look like Namespace UI.WebControls.