I wasn't able to set my new form as a startup form, it complained about it not existing.
But after some minutes I tried with typing "Namespace.NewForm" and that worked.
In my other project, The startup is set as this:
Application.Run(new MyForm());
Why did I have to specify namespace when changing startup form in this project?
Presumably because you didn't have a using directive for it:
using SomeNamespace;
...
Application.Run(new SomeForm());
There's nothing particularly different about the code used to call Application.Run - it's just normal C# code, following the normal rules of C#.
Use a using directive so you do not have to fully qualify the types within the namespace in question.
using MyNameSpace;
It's also worth pointing out that using directives in C# do not give you access to namespaces nested in the namespace you specify (just in case you are wondering). This means that
using System;
does not give you access to System.IO
It sounds like there's more context here than you're sharing. Regardless of what you're doing, any place where you reference MyForm will need to be able to resolve that reference to a fully-qualified class (including namespace). This means that it will either need to be fully-qualified or it will need its namespace included in the using statements at the top of the file (and be unambiguous).
Does your "working" version already have the using directive and the "non-working" version simply does not? Do your versions attempt to set the startup form in different places?
I suspect that the "working" version has the using directive already in place and that, for whatever reason, it's not in place in the "non-working" version.
Related
Hopefully an elementary question, but one to which I can't find an answer...
This Microsoft documentation leads me to believe that I need to add a using directive for my main project's namespace to my test class files, in order to be able to access the main project's members.
using MainProject;
namespace MainProject.Tests;
[TestClass]
public class UnitTests
{
...
}
However, when I do so, Visual Studio Code (with the Microsoft C# extension) tells me the MainProject import is unnecessary. And indeed, my unit tests manage to access the main project members without the using statement.
Both the main project and the test project exist in separate directories and have separate .csproj files. Both live inside a parent folder containing an .sln file to which each has been added. The test project's .csproj file has a reference to the main project's.
The main project's namespace is: MainProject
The test project's namespace is: MainProject.Tests
I have opted into global usings in the test project file, and there is a usings.cs file, which contains one line:
global using Microsoft.VisualStudio.TestTools.UnitTesting;
Where is the magic happening? (For example, is there a rule that the "child" namespace automatically "inherits" the types declared in the parent?)
Many thanks for your help.
A usising statement simple brings the namespace in scope for name resolution, it has nothing to do with directories or assemblies.
The namespace does the same thing, except it has a hierarchical basis and so isn’t as flexible.
In essence, there is no magic, you have misunderstood what is happening.
I found the official documentation explaining that namespace scopes "nest", and that the inner namespace has access to the members of the outer. Here it is:
https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/language-specification/basic-concepts#77-scopes
(The second bullet point in section 7.7.1 describes the rule.)
When I last worked with C#, a long time ago, it was similar enough to Java to be virtually indistinguishable. But a lot has changed.
For example, I had forgotten that the Java-style namespace declarations are a recent addition to dotnet:
namespace MyCompany.MyProduct;
...
We used to have to do it like this:
namespace MyCompany
{
namespace MyProduct
{
...
}
}
Looking at it this way, it's easy to see why one might implicitly presume that the inner scope has access to the members of the outer, without having to read the rule from the language spec. If you're used to JavaScript scopes, for example, and your mental model of namespaces looks like the above, then the idea just seems natural.
However, if you're used to the way package imports work in Java, then this can seem very strange.
I am having some namespace issues. In my solution I have the following solutions ;
Services
Services.WebApi
Now, as an example in my WebApi controller I want to reference a sub namespace of the above Services solutions namespace, i.e.;
using Services.Data;
However, it is not resolving the Services from the project reference? Instead its trying to reference from a small namespace inside the Service.WebApi.Services of the current solution? So, it is looking like VS is automatically assuming the local namespace in stead of the referenced one? (i.e. if I hover over the Services text of Services.Data, intellisense is showing 'namespace Services.WebApi.Services'.
I've used this before with no issues, any ideas whats going on here?
To note the Services project is added as a reference and both are running .NET 4.6.
If you wish to indicate that your intention is to start at the "top" of the namespace hierarchy, you can use the global alias:
using global::Services.Data;
You can try using an alias for your Services reference. In the References List, select your Reference properties, And you'll see an Alias property. Change in to the name you want and then change your using to that name. Let's say you set the Alias to ExternalServices. You'll need to add this to your code:
extern alias ExternalServices;
using ExternalServices::Services.Data;
That would solve your problem.
I am trying to use using System.Windows.Threading; but it gives me
The type or namespace name 'Threading' does not exist in the namespace 'System.Windows`.
I have the latest version of .NET.
It's in WindowsBase.dll, after add the reference, it works!
(if you don't know how to add reference, see this tutorial.)
Please make sure you've added a reference to WindowsBase.dll to your project and then you should be good to go. have a look at - https://msdn.microsoft.com/en-us/library/system.windows.threading.dispatchertimer%28v=vs.110%29.aspx
If you're still having trouble please attach your .csproj file.
You have to add a reference to the assembly containing the class you want to use.
Additionally, you probably don't want to use WPF classes (from System.Windows.Threading) if you did not create the project with the WPF application wizard.
Edit: In Windows Forms applications, the obvious choice for a timer is System.Windows.Forms.Timer, and in some cases System.Threading.Timer.
It's using System.Threading; not using System.Windows.Threading. Don't know if you used that in your code and just made a mistake on the question, but there it is.
I'm working on app which uses a lot of external assemblies (newtonsoft.dll, Yahoo Yui compressor.dll, fleck.dll etc). In each c# file I need to add using statement with all those assemblies. Is it possible to create my own assembly (i.e. LIBRARY.dll) containing all the dll's and refer only to this in all c# files?
No. Firstly, using directives refer to namespaces, not assemblies (assembly references are defined at the project level). Secondly: you almost certainly don't actually need all of them in every file. But: you can create a new-file-template with the ones you are likely to need. But frankly it is usually easier to either copy/paste them, or just add them when they are needed. In the IDE, this is as simple as pressing ctrl+.,ret after a type name that doesn't resolve... so MySpecialTypectrl+.,ret should add the missing using directive to resolve MySpecialType.
using does not refer to assembly, but to namespace. So the answer is "no"...
using System; // you are using items in the System namespace
using System.IO; // you are using items in the System.IO namespace
No. Usages of individual types need to be resolved to the namespaces where they are defined in. So, you will still need to include the resolution paths in your usings.
I have a class library I've built for a coworker to use that, after giving her the .dll file, I cannot get to work. The name of the .dll file is "BatchDashboard." The name of the namespace is "BatchDashboard," and the name of the class (there is only one) is "BatchDashboard." Is it a problem to have all three similarly named? Visual Studio is able to add the reference just fine. However, this statement:
using BatchDashboard;
spits out the following error:
The type or namespace name 'BatchDashboard' could not be found (are you missing a using directive or an assembly reference?
Likewise, I cannot instantiate a new 'BatchDashboard' object.
Could someone tell me what I am doing wrong?
Thx!
EDIT
I have tried adding the reference to another test project on my computer and receive the same results.
SECOND EDIT
Changing the access modifier to public for the "BatchDashboard" class fixed the issue with the using statement. However, when I try to instantiate an object like so:
BatchDashboard batch = new BatchDashboard();
I got the following error:
'BatchDashboard' is a namespace but is used like a 'type'
It was necessary for me to have different class and namespace names to work. Thank you!
I think, I know what problem you have. When you created your class file, you probably didn't change access to your class to "public". In .Net, unless you have public members in the assembly, the namespace wouldn't be found in "using" directive.
Basically, check if the class you have is a "public class"
Here are my best guesses:
You compiled it against the wrong CPU target
You have a dependency on a Runtime library that should be added as a reference to the
project also.
Make sure that:
The library is added as reference to the project
That library is in a equal or prior .NET version compared to your project's .NET version.