Products

Solutions

Resources

Partners

Community

Blog

About

QA

Ideas Test

New Community Website

Ordinarily, you'd be at the right spot, but we've recently launched a brand new community website... For the community, by the community.

Yay... Take Me to the Community!

Welcome to the DNN Community Forums, your preferred source of online community support for all things related to DNN.
In order to participate you must be a registered DNNizen

HomeHomeArchived Discus...Archived Discus...Developing Under Previous Versions of .NETDeveloping Under Previous Versions of .NETASP.Net 2.0ASP.Net 2.0Using Web Application Projects with DNN 4.xUsing Web Application Projects with DNN 4.x
Previous
 
Next
New Post
6/2/2006 7:34 AM
 

The point that 'imports' helps reducing code is clear.

But my question was, why does the DNN-Code compile without having that 'imports'-statement and without entering the full code-path?

Wolfgang, a little bit confused

 
New Post
6/2/2006 10:44 AM
 

Imports do not make things available to your application like a reference does, it only allows you use the element names without a fully qualified name. In other words, Imports is just used to allow shorter references in your code or to specify classes with same names.

For example, from a referenced project these all refer to the same element...

Reference MyNamespace
1) Dim x As MyNamespace.MyProject.MyClass

Imports MyNamespace
2) Dim x As MyProject.MyClass

Imports MyNamespace.MyProject
3) Dim x As MyClass

The only special case with imports is when similar class names are used like this...

Imports win = System.Windows.Forms, web = System.Web.UI.WebControls
Dim winLabel As win.Label
Dim webLabel As web.Label

Finally, DNN compiles because all the names are qualified within the DotNetNuke namespace as part of the project.

Does that help clarify the issue?


Dwayne J. Baldwin
 
New Post
6/2/2006 11:17 AM
 
Vladan Strigo wrote

The main diffrence is that it is in a seperate solution....

Correct...but what is a solution?  A logical container of projects.  The projects are the same.  I personally would use both at different times.  For people that need to make core changes it is helpful to have core projects open at the same time.  Bu I agree with you when just working on a module just having that project open is the best.

Vladan Strigo wrote
there will be no problems (I didn't have them in VS2003 either), only if you select your references to be copy local= false, this way you module does not create a conflict because it doesnt transfer the DotNetNuke (or any other DNN) dll to the main bin - just itself


This issue is well document is VS 2003 see the following http://support.microsoft.com/default.aspx?scid=http://support.microsoft.com:80/support/kb/articles/q313/5/12.ASP&NoWebContent=1&NoWebContent=1

From the link
“Cause

•Your solution contains projects that are compiled to the same output folder
.•The Copy Local property on one of the referenced assemblies or projects is set to False.”

I am interested if the VS team specifically address this issue.  Simple modules never showed this issue but modules that consisted of multiple projects that build to the same bin would have this issue.


 


 
New Post
6/2/2006 11:21 AM
 
wb wrote
I wonder why you (and I) have to add those 'imports' statements. I am rather new to VB.net, but as far as I understand, using any class or module-method somewhere down in a namespace hierarchy needs to have declared that hierarchy by the imports statement.


Web Site projects (WSP) store namespace information in the web.config. 

     <namespaces>
        <add namespace="System.ComponentModel" />
        <add namespace="System.Data" />
        <add namespace="System.Data.SqlClient" />
        <add namespace="System.Drawing" />
        <add namespace="Microsoft.VisualBasic" />
        <add namespace="System.Globalization" />
        <add namespace="DotNetNuke.Services.Localization" />
        <add namespace="DotNetNuke.Entities.Users" />
        <add namespace="DotNetNuke" />
        <add namespace="DotNetNuke.Common" />
        <add namespace="DotNetNuke.Data" />
        <add namespace="DotNetNuke.Framework" />
        <add namespace="DotNetNuke.Modules" />
        <add namespace="DotNetNuke.Security" />
        <add namespace="DotNetNuke.Services" />
        <add namespace="DotNetNuke.UI" />
        <add namespace="DotNetNuke.Entities.Portals" />
        <add namespace="DotNetNuke.Common.Utilities" />
        <add namespace="DotNetNuke.Services.Exceptions" />
        <add namespace="DotNetNuke.Entities.Tabs" />
      </namespaces>

I could have added the same namespace imports under the refrences tab of the Web Application Project (WAP) proprty page.  I just decided to add imports instead.

Bert
 
New Post
6/2/2006 11:23 AM
 

Bertcord,

yes my solution also suffers from the dnn controls problem - fortunatly it works as mentioned in the above posts.

I will spend some time on this in the near future again.

And also, I've seen your solution yes - made like this it is pretty much what I advise.

 

 


Thanks,
Vladan Strigo
NETMedia

My website: Vladan.Strigo.NET

Vladan.Strigo.NET: Projects
* Advanced VS2005 development approach - BlankModule
* DNN & Microsoft Ajax best practices guidance

Vladan.Strigo.NET: Resources
* Comprehensive list of DNN 4 Module development resources

 
Previous
 
Next
HomeHomeArchived Discus...Archived Discus...Developing Under Previous Versions of .NETDeveloping Under Previous Versions of .NETASP.Net 2.0ASP.Net 2.0Using Web Application Projects with DNN 4.xUsing Web Application Projects with DNN 4.x


These Forums are dedicated to discussion of DNN Platform and Evoq Solutions.

For the benefit of the community and to protect the integrity of the ecosystem, please observe the following posting guidelines:

  1. No Advertising. This includes promotion of commercial and non-commercial products or services which are not directly related to DNN.
  2. No vendor trolling / poaching. If someone posts about a vendor issue, allow the vendor or other customers to respond. Any post that looks like trolling / poaching will be removed.
  3. Discussion or promotion of DNN Platform product releases under a different brand name are strictly prohibited.
  4. No Flaming or Trolling.
  5. No Profanity, Racism, or Prejudice.
  6. Site Moderators have the final word on approving / removing a thread or post or comment.
  7. English language posting only, please.
What is Liquid Content?
Find Out
What is Liquid Content?
Find Out
What is Liquid Content?
Find Out