|
It did (the second line does not cause and error) but its ugly.
How can I make it work without the full prefix?
|
|
|
|
|
you could try
using Microsoft.Office.Interop;
using Microsoft.Office.Interop.Word;
PS: more using statements may increase the probability of a type name conflict. (e.g. if you also add a using for Excel, then Document might become ambiguous).
|
|
|
|
|
This is getting odd...
using Microsoft.Office.Interop;
using Microsoft.Office.Interop.Word;
class Program
{
static void Main(string[] args)
{
Word.Application objWord;
Word.Document objDoc;
Application objWord2;
Document objDoc2;
}
}
|
|
|
|
|
That's because "Word" is a namespace... A "using" statement is a full declaration, not a partial one.
If you want to prefix them with "Word", try this:
using Word = Microsoft.Office.Interop.Word;
That defines "Word" as an alias for that whole namespace, so you can just always use Word.Application or Word.Document
|
|
|
|
|
Nothing odd about it, Eddy already told you "C# doesn't like partial namespaces". You either give the fully qualified type (always OK) or just the simple type name (requires a using that holds all the missing parts).
|
|
|
|
|
|
Really? First I've heard of it -- another reason to avoid using using directives. 
|
|
|
|
|
Without using directives code is unreadable. And I have never had any issues with namespaces.
Conflicts, that may occur are quite easy to resolve and are reported as error by compiler, so it is difficult to have something wrong in compiled aplication.
Don't forget to rate answer, that helped you. It will allow other people find their answers faster.
|
|
|
|
|
Łukasz Nowakowski wrote: Without using directives code is unreadable.
Quite the contrary. People post pieces of code on here all the time without indicating the full names of classes. How are we supposed to know exactly which type of Widget you're using?
|
|
|
|
|
You're right, but imagine you have a big application, where everything is written with FQN. At least for me it would be a nightmare to read it... You couldn't see variable name without scrolling the screen right.
I didn't have readability on forums like this in mind, just readability in every day life.
Don't forget to rate answer, that helped you. It will allow other people find their answers faster.
|
|
|
|
|
Łukasz Nowakowski wrote: have a big application
Yes, I do.
Łukasz Nowakowski wrote: without scrolling the screen right
I have a widish screen and I break the longer names as appropriate.
Łukasz Nowakowski wrote: readability on forums
... is very important, whether asking or responding don't assume that the other patry is familiar with the class you're using.
Łukasz Nowakowski wrote: in every day life
You get used to it; it's not a big deal. I've been doing it that way since I first learned C# in 2002.
|
|
|
|
|
PIEBALDconsult wrote: How are we supposed to know exactly which type of Widget you're using?
Through our sheer awesome awesomeness.
|
|
|
|
|
But then I'm blinded and can't see the screen at all.
|
|
|
|
|
We are so awesome that the answer should appear without needing any input. 
|
|
|
|
|
Yes, quite often that is the case, but still we need to share it with the world.
|
|
|
|
|
What is so odd about that? You have the "using" statement pointing to the Word namespace, you don't need to prefix Application with it (as in the second section that works).
A bit about namespace type name conflicts: alias the using statement. That way you don't have to type System.XML.Blah.Foo.Bar.Typename if you also have System.Word.Blah.Meh.Foo.Bar.Typename, you can type Foobar.Typename to get one, and MehFoo.Typename to get the other by aliasing the using statment via "using Foobar = System.XML.Blah.Foo.Bar" and "using MehFoo = System.Word.Blah.Meh.Foo.Bar".
|
|
|
|
|
Hello,
I'm having some problems in my solution. I have a project (a .dll) that contains interfaces for all my other projects. I decided to remove the namespaces and move them all into the same, and when I had done that I updated all my files to compile. However, I am now getting an exception while loading that a type that was previously in a namespace in the interface dll cannot be loaded.
"{"Could not load type 'Moonlite.ExtensionApi.GlobalInterfaces.IProjectTemplate' from assembly 'Moonlite.ExtensionApi, Version=1.0.1.0, Culture=neutral, PublicKeyToken=null'.":"Moonlite.ExtensionApi.GlobalInterfaces.IProjectTemplate"}"
I searched my entire harddrive, searched the GAC, literally everything I can think of, however the only copy of the interface dll is in the binary folder. I can't think of anything else I could do.
Please note that this is very urgent, as I have an upcoming release, so any help is appreciated.
Another note - I use MEF.
Thanks,
Theo
|
|
|
|
|
Have you shutdown VS and restarted it?
Please note asking for urgent help is considered rude here.
I know the language. I've read a book. - _Madmatt
|
|
|
|
|
Have you tried a clean build? i.e. remove the obj folders, click Build/CleanSolution, then build it all over.
|
|
|
|
|
Mark:
Yes, I have shutdown VS and restarted it.
I'm sorry - it will not happen again.
Luc:
Yes - I tried removing all binary files, all bin/obj folders, etc.
|
|
|
|
|
Do you have a clean development environment in a VM? If so, copy the source-files and rebuild there. If no, you might as well create such an environment while waiting for a decent answer that actually solves the problem.
I are Troll 
|
|
|
|
|
I'm not sure I get what you mean. Could you please elabroate?
|
|
|
|
|
You could install Windows and Visual Studio in a Virtual Machine, using Virtual PC 2007[^] for example. That way you'd always have a clean environment
As is now, it would be guessing at the problem. Did you by any chance register any of the dll's as COM-controls?
I are Troll
|
|
|
|
|
That seems a bit much work for that - I think I'd rather keep trying things. Thanks for the tip, though.
I didn't register them as COM, no.
|
|
|
|
|
Is the old version in the GAC?
Oh, you said not. 
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
