How do I reference a Namespace in .NET MVC3 with the Razor view engine?
I understand this can be done in C#:
#using Namespace;
However in VB this doesn't seem to work:
#Imports Namespace
(i'm talking about inside a .vbhtml file)
You're using the correct syntax for VB:
#Imports My.Full.Namespace
What I've found in a quick play around is:
Sub namespaces of the MVC project will be picked up by intellisense once the #Imports statement is added - must be the complete namespace.
If you're referencing a namespace outside of the current MVC project then intellisense won't pick it up unless you do a rebuild.
#Jonathan is correct, it's the correct syntax and it needs the full namespace of your extension methods.
If your extension methods are still not recognised, you may need to insert this import before your own namespace:
#Imports System.Web.Mvc.HtmlHelper
When I added this intellisense offered my extension methods. I think it's something to do with having a reference to System.Web.WebPages, which also defines a HtmlHelper class. Perhaps that explains why migrating the code to a new project solved the problem.
Unfortunately, the intellisense problem with the Import statement still persists, it doesn't offer the namespaces up.
I realise this answer is somewhat late in coming, however this has held me up half of the day - hope it helps someone else avoid this pitfall.
Related
I am trying to use the generic DbSet class. I have tried adding the following references so far to my solution because the MSDN documentation states that DbSet lives inside System.Data.Entity:
However, as shown below I still cannot add a reference to System.Data.Entity, the only suggestion intellisense has is EntityClient which does not contain DbSet:
Resharper/Intellisense is not giving me any other suggestions of namespaces I could possibly add.
I have tried cleaning and rebuilding my solution, and I am using the .Net Framework 4 full version (not the client version).
I have tried using NuGet to search for EntityFramework and have found one result which I have added to no avail as is show below:
What DLL file do I need to add to my solution to add a reference to System.Data.Entity and use the DbSet class?
Thanks
The same MSDN reference page that you mention says that you need to reference EntityFramework.dll in your project.
Note that namespaces and assemblies are not the same thing. The following statement is a little over-simplified, but you can think of namespaces as residing inside (or becoming available by referencing) an assembly.
So, once you've referenced the assembly, you will still need the using System.Data.Entity; directive.
I've just installed Blend 4 and are trying to use it with a rather big VS2010 project that includes a couple of C++/CLI assemblies with some native code. For a lot of controls I get a Blend error like 'The name XXX does not exist in the namespace 'clr-namespace:YYY' when trying to open the design view.
I've searched the web (including this forum) for similar errors and have made sure that I've followed all available suggestions, like e.g. making sure I have an AnyCPU configuration, that I don't use e.g. 'x64\Debug' as the output folder, and that I have the proper namespace declaration in my XAML (using 'assembly' in my clr-namespace declaration).
I've also made a simple, new project that only accesses one of the assemblies with the issue, but I still get the error.
It looks to me that the issue is related to assemblies that references any of the C++/CLI assemblies that includes some unmanaged code. I do not seem to get the error for assemblies that references managed-code-only assemblies.
What could cause the errors ?
Regards,
Leif
Little response here, so maybe I should rewrite my question a bit:
Has anyone successfully used Expression Blend for a project that uses assemblies with unmanaged code ?
Regards,
Leif
had a similar problem: project compiled correctly without error in VB 2010, but got error when opening it in Expression Blend 4 (beautyful tool, by the way):
The name XXX does not exist in the namespace "clr-namespace:YYY".
at line:
<CollectionViewSource x:Key="YYYViewSource" d:DesignSource="{d:DesignInstance {x:Type my:YYY}, CreateList=True}" />
In my case it was an Entity in my edmx, a FunctionImport named "YYY" with a ComplexType "YYY_Result", and my XAML code at the CollectionViewSource referenced to that entity "YYY".
This XAML code generated No error in VB 2010, compiled and ran perfectly well (compiled also correctly in Blend), however no design view in Blend.
Solution: I realized my mistake at the x:Type in CollectionViewSource and corrected name from "YYY" to "YYY_Result" and it worked:
<CollectionViewSource x:Key="YYYViewSource" d:DesignSource="{d:DesignInstance {x:Type my:YYY_Result}, CreateList=True}" />
Conclusion:
Maybe this answer is not exactly related to your problem concerning the C++/CLI assemblies with some unmanaged native code, and maybe yes.
This case was just a nice example of a project compiling correctly in VB 2010, but same XAML generated above error message in Blend 4 when creating the design view (many users reported similar issues at this forum).
I have a solution that contains many projects all using the same root namespace. No code files explicitly name a namespace. So lets say the root namespace is ExampleRootNamespace.
Now a problem comes into play when I want to add an explicitly named namespace to one of the code files I am working on. I want to be able to isolate this code from the rest of the assembly to be able to run FxCop against it. So I add something like Namespace Interfaces.CSV to the code file.
This causes any code that references this assembly to need to say Imports ExampleRootNamespace.Interfaces.CSV. So far so good. I can even run FxCop against the assembly. The problem now is that in other assemblies I cannot say any longer things like:
Public class frmInputBoolean Inherits
ExampleRootNameSpace.frmFormTemplate
Visual Studio is now asking me to rename the namespace to:
Public class frmInputBoolean Inherits
Global.ExampleRootNameSpace.frmFormTemplate
There are hundreds of errors related to this. So my questions are:
1) Why would basically naming a namespace under the root for the first time cause issues with the program?
2) Are there any workarounds to this issue without renaming?
I also want to add that with regards to ExampleRootNamespace.Interfaces.CSV I am not referencing this anywhere in the codebase. I'm currently just referencing it from a unit test project. So I don't see why adding this namespace causes an issue.
In C# try utilizing the USING operator with your namespace.
using ExampleRootNamespace = newExampleRootNamespace;
On the ones that have the global issue.
sadly, I do not believe an easy solution exists for you in VB.NET
Well, it appears this may be a bug in Visual Studio 2008. As the code has not changed but the problem with the required Global prefix is no longer there.
I say this because I checked out one of the offending code files and tried to add (as Meakins suggested):
Imports ExampleRootNamespace = Global.ExampleRootNamespace
When I did this two things happened.
1) The error highlighting and error correction suggestions were removed and ExampleRootNamespace was recognized by Visual Studio. Also the code now compiles.
2) Imports ExampleRootNamespace = Global.ExampleRootNamespace is not valid because of the use of Global in the imports statement. Visual studio says: "'Global' not allowed in this context; identifier expected." This Means that this line of code will not compile. So I removed it all together. Oddly enough despite it not being there (and thus the code returning to as before) there are no more errors.
I also restarted visual studio (but after doing the above). This is quite odd if you ask me!
There seemes to be a consistent problem with the following situation:
Say you have a VS2008 solution, consisting of a (say console) application written in vb.net, and a class library written in c#. The application references the class library
project.
This, of course, complies and works well. However, when you right-click (in the vb.net application code) a function prototype/object type defined in the class library, and select "Go to definition", the object browser opens providing you with the the list of methods available for the class the class library consists of. BAD. However, if you try to do the same when both the application and cl are in c#, this works just fine and you navigate driectly to the relevant function/class.GOOD.
Known issue? Solvable?
Did you try adding a project reference instead of a DLL reference? A project reference should take you to the actual relevant code in the other assembly.
It's a known issue, the workaround are two: use ctrl+, or use some plugin that add this function, like resharper.
There is Aliases feature in C# that allows to work with different assemblies, containing equally named entities (classes, structures, enums). It is activated when you choose an assembly an referenced assemblies list. But I can't see any similar in VB.NET project. Is there such a feature in VB.NET? If no, why?
Imports Data = System.Data
Will allow you to use:
Data.SqlClient
Similar to what you've seen in C#. Here is a blog post that discusses the usage. Here is an older one that laments another feature C# has that VB.NET doesn't (didn't?)
I think you are talking about the /reference:alias=filename option accepted by the C# compiler. That allows you to rename the root namespace of the assembly. Very handy when you need to reference both an old and a new version of an assembly that otherwise contain classes with the same namespace and class names. Without that option, you'd always get an ambiguous identifier compile error. The namespace alias feature can't fix that.
No, VB.NET doesn't have that. Why? Ask at connect.microsoft.com.
This is an example for how to do it, in both C# and VB.NET