Our team uses rule "usings inside namespace".
There are two classes:
namespace Foo.Bar
{
public class SomeClass
{
public int CalcSomething()
{
return 1;
}
}
}
and:
namespace Foo
{
using System;
class Program
{
static void Main(string[] args)
{
var someObj = new SomeClass();
Console.WriteLine(someObj.CalcSomething());
}
}
}
Since SomeClass is in Foo.Bar namespace, quick actions menu is offering to resolve namespace, but result differs between VS2015:
and VS2017:
Both versions have Productivity Power Tools installed, if this matters. Both use appropriate PPT extension versions.
How to change resolution behavior for VS2017? I don't need "long namespace", because it's superfluous here.
Related
I'm struggling with proper dependencies versioning on releases. I've read in some articles that every change to AssemblyVersion in a library will cause the need of rebuilding all assemblies referencing this library. If it's true I need to be super careful when designing release cycles of dependent assemblies, right?
I wanted to verify the thesis by myself and... well, I noticed it is not the truth at all.
I made a console app which referenced dep1.dll (assembly version 1.0.0.0) and built it. Then I changed dep1.dll to version 2.0.0.0, built it and swapped it with version 1.0.0.0. When running console application I expected error "The assembly dep1.dll with version 1.0.0.0 couldn't be found". And you know what? Nothing special happened, the app used the library like it was targetting that version since the beginning.
ConsoleApp1/Program.cs
using dep1;
using System;
namespace ConsoleApp1
{
class Program
{
static void Main(string[] args)
{
var a = new Class1();
a.Prop1 = "asdf";
Console.WriteLine(a.Prop1);
}
}
public class Implementation : Interface1
{
public int Super { get => throw new NotImplementedException(); set => throw new NotImplementedException(); }
}
}
dep1/Class1.cs
namespace dep1
{
public class Class1
{
public string Prop1 { get; set; }
}
public interface Interface1
{
int Super { get; set; }
}
}
As you can see, it's the same with interfaces.
Could you please explain why my test didn't work? This, other SO answers (1) and article by haacked on versioning interfaces really confused me.
My project has 2 DLLs, one is Android specific and the other is platform independent. The independent DLL loads the Android assembly and calls the GetTypes method but it is not returning all of the public classes. The Android DLL has 3 classes, 2 are static with static methods only. Only one can be instantiated. The static classes are not returned.
Class1.cs (compile to dll in VS):
using System;
using System.Reflection;
namespace ClassLibrary1
{
public class Class1
{
public void test()
{
Assembly asm = Assembly.Load("ClassLibrary2");
Type T = asm.GetType("ClassLibrary2.Class2");
T.InvokeMember("Method", BindingFlags.Static | BindingFlags.InvokeMethod, null, T, null);
}
}
}
Class2.cs (Compile to a separate dll in VS):
namespace ClassLibrary2
{
public static class Class2
{
public static void Method()
{
return;
}
}
}
UnityClass.cs (Assign to a Empty GameObject in Unity 5.x):
using UnityEngine;
using System;
class UnityClass : MonoBehaviour
{
public void Start()
{
var x = new ClassLibrary1.Class1();
x.test();
}
}
Have a look at the following note in the msdn regarding BindingFlags:
You must specify Instance or Static along with Public or NonPublic or no members will be returned.
If you add BindingFlags.Public to your call you should get the member.
Also the 4th parameter target is not required when invoking a static member, you don't have to pass in the type as target, just use null.
As a last note, from personal experience i recommend to get the desired member first by using Type.GetMethod, Type.GetField, ... instead of using InvokeMember. That gives you the possibility to null check the return value to verify that you have found the member you are searching for. That is better for debugging as well as throwing meaningful exceptions during runtime.
I don't understand why an explicit reference isn't required in this situation:
//SomeStaticClass.cs
namespace WhyDontINeedUsingStatement {
public static class SomeStaticClass {
public static string Thingy {
get { return "Behold! A thingy!"; }
}
}
public class SomeNonStaticClass {
public void DoSomethingUseful() {
var foo = 9;
}
}
}
// /SomeNamespace/SomeBoringClass.cs
namespace WhyDontINeedUsingStatement.SomeNamespace {
public class SomeBoringClass {
public static void DoSomething() {
var whatever = SomeStaticClass.Thingy;
var blah = new SomeNonStaticClass();
blah.DoSomethingUseful();
}
}
}
Why doesn't this require a using WhyDontINeedUsingStatement at the top? Aren't these separate namespaces, even though they start with the same thing?
I get that C# namespaces aren't quite the same thing as Java packages (and don't affect access control), but not why the second class is able to reference stuff from the first.
According to C# Language Specification Version 5.0, Section 9.2, it seems like using the . in a namespace declaration is syntactic sugar :
The qualified-identifier of a namespace-declaration may be a single
identifier or a sequence of identifiers separated by “.” tokens. The
latter form permits a program to define a nested namespace without
lexically nesting several namespace declarations. For example,
namespace N1.N2
{
class A {}
class B {}
}
is semantically equivalent to
namespace N1
{
namespace N2
{
class A {}
class B {}
}
}
So from inside of N2 you can see N1, hence why you can use it.
I'm quite new to C#, and have made a class that I would like to use in my main class. These two classes are in different files, but when I try to import one into the other with using, cmd says says
The type or namespace name "MyClass" could not be found (are you missing a using directive or an assembly reference?
I know that in Java I have to mess around with CLASSPATH to get things like this to work, but I have no idea about C#.
Additional details:
As you've probably figured out, I'm compiling and executing via command prompt. I'm compiling my non-main class using /target:library (I heard that only main classes should be .exe-files).
My code looks like this:
public class MyClass {
void stuff() {
}
}
and my main class:
using System;
using MyClass;
public class MyMainClass {
static void Main() {
MyClass test = new MyClass();
/* Doesn't work */
}
}
I have tried to encompass my non-main class with namespace MyNamespace { } and importing that, but it doesn't work either.
UPDATE: As of C# 6, if you want to use the static members of a class without specifying the class name, you can use the using static directive to import the static members into the current scope, like this:
using static MyNamespace.MyClass;
Although this is not what the original question is about, you get a similar error to the one OP gets, so I'm providing it for completeness.
Answer to OP's question:
using is for namespaces only - if both classes are in the same namespace just drop the using.
You have to reference the assembly created in the first step when you compile the .exe:
csc /t:library /out:MyClass.dll MyClass.cs
csc /reference:MyClass.dll /t:exe /out:MyProgram.exe MyMainClass.cs
You can make things simpler if you just compile the files together:
csc /t:exe /out:MyProgram.exe MyMainClass.cs MyClass.cs
or
csc /t:exe /out:MyProgram.exe *.cs
EDIT:
Here's how the files should look like:
MyClass.cs:
namespace MyNamespace {
public class MyClass {
void stuff() {
}
}
}
MyMainClass.cs:
using System;
namespace MyNamespace {
public class MyMainClass {
static void Main() {
MyClass test = new MyClass();
}
}
}
I know this is very old question but I had the same requirement and just discovered that after c#6 you can use static in using for classes to import.
I hope this helps someone....
using static yourNameSpace.YourClass;
Well what you have to "import" (use) the namespace of MyClass not the class name itself. If both classes are in the same namespace, you don't have to "import" it.
Definition MyClass.cs
namespace Ns1
{
public class MyClass
{
...
}
}
Usage AnotherClass.cs
using Ns1;
namespace AnotherNs
{
public class AnotherClass
{
public AnotherClass()
{
var myInst = new MyClass();
}
}
}
If they are separate class files within the same project, then you do not need to have an 'import' statement. Just use the class straight off. If the files are in separate projects, you need to add a reference to the project first before you can use an 'import' statement on it.
If the other class is compiled as a library (i.e. a dll) and this is how you want it, you should add a reference from visual studio, browse and point to to the dll file.
If what you want is to incorporate the OtherClassFile.cs into your project, and the namespace is already identical, you can:
Close your solution,
Open YourProjectName.csproj file, and look for this section:
<ItemGroup>
<Compile Include="ExistingClass1.cs" />
<Compile Include="ExistingClass2.cs" />
...
<Compile Include="Properties\AssemblyInfo.cs" />
</ItemGroup>
Check that the .cs file that you want to add is in the project folder (same folder as all the existing classes in the solution).
Add an entry inside as below, save and open the project.
<Compile Include="OtherClassFile.cs" />
Your class, will now appear and behave as part of the project. No using is needed. This can be done multiple files in one shot.
MyClass is a class not a namespace. So this code is wrong:
using MyClass //THIS CODE IS NOT CORRECT
You should check the namespace of the MyClass (e.g: MyNamespace). Then call it in a proper way:
MyNamespace.MyClass myClass =new MyNamespace.MyClass();
using is used for importing namespaces not classes.
So if your class is in namespace X
namespace X
{
public class MyClass {
void stuff() {
}
}
}
then to use it in another namespace where you want it
using System;
using X;
public class MyMainClass {
static void Main() {
MyClass test = new MyClass();
}
}
namespace MyNamespace
{
public class MyMainClass
{
static void Main()
{
MyClass test = new MyClass();
}
}
public class MyClass
{
void Stuff()
{
}
}
}
You have no need for using a namespace then because it is all encompased in the same namespace.
If you are unsure of what namespace your class is located, type the class (case sensitive you wish to use) then with your cursor on the class, use CTRL + . and it will offer you a manual import.
I have a dll that I'm working with, it contains a class foo.Launch. I want to create another dll that subclasses Launch. The problem is that the class name must be identical. This is used as a plugin into another piece of software and the foo.Launch class is what it looks foe to launch the plugin.
I've tried:
namespace foo
{
public class Launch : global::foo.Launch
{
}
}
and
using otherfoo = foo;
namespace foo
{
public class Launch : otherfoo.Launch
{
}
}
I've also tried specifying an alias in the reference properties and using that alias in my code instead of global, that also didn't work.
Neither of those methods work. Is there a way I can specify the name of the dll to look in within the using statement?
You'll need to alias the original assembly and use an extern alias to reference the original assembly within the new one. Here's an example of the use of the alias.
extern alias LauncherOriginal;
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
namespace foo
{
public class Launcher : LauncherOriginal.foo.Launcher
{
...
}
}
Here's a walkthrough that explains how to implement that.
Also, you'd mentioned that you tried to use an alias before and encountered problems but you didn't say what they were, so if this won't work then please mention what went wrong.
as Chris said, you can use an alias on your original assembly.
If you can't you that, then you might be able to cheat by using a 3rd assembly
Assembly1.dll (your original)
namespace foo {
public class Launch {}
}
Assembly2.dll (dummy)
namespace othernamespace {
public abstract class Dummy: foo.Launch {}
}
Assembly3.dll (your plugin)
namespace foo{
public class Launch: othernamespace.Dummy{}
}
I'm not even proud of this!
Class name can be identical if it's defined in another namespace, but it boggles the mind why anybody would want to do that to themselves.
Maybe you need to use extern aliases.
For example:
//in file foolaunch.cs
using System;
namespace Foo
{
public class Launch
{
protected void Method1()
{
Console.WriteLine("Hello from Foo.Launch.Method1");
}
}
}
// csc /target:library /out:FooLaunch.dll foolaunch.cs
//now subclassing foo.Launch
//in file subfoolaunch.cs
namespace Foo
{
extern alias F1;
public class Launch : F1.Foo.Launch
{
public void Method3()
{
Method1();
}
}
}
// csc /target:library /r:F1=foolaunch.dll /out:SubFooLaunch.dll subfoolaunch.cs
// using
// in file program.cs
namespace ConsoleApplication
{
extern alias F2;
class Program
{
static void Main(string[] args)
{
var launch = new F2.Foo.Launch();
launch.Method3();
}
}
}
// csc /r:FooLaunch.dll /r:F2=SubFooLaunch.dll program.cs