 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
.NET Forum / Languages / VB.NET / March 2008In any project, Can't we refer classes directly, (without adding physically in the project)?
Hi ! I am new to .net. Presently, Working in vb.net 1.1 i have Created one class project and one client project (2 separate solutions) In the client project , if I try to ' add reference' for class, nothing is shown under project bar. I have to cumpulsorily add class project into my client project (add existing class), then only it shows class name under reference-project bar. does it mean every time I have to add required no. of classes physically, in any project? Then again give the reference of each? Can't it directly refered without adding physically? Thanks, Regards, Rachana > Hi ! > I am new to .net. Presently, Working in vb.net 1.1 [quoted text clipped - 12 lines] > Regards, > Rachana Rachana, Would you mind referencing your class (assuming a DLL), from "browse" tab instead of integrating your project physically? Onur Güzel > i have Created one class project and one client project (2 separate > solutions) > In the client project , if I try to ' add reference' for class, > nothing is shown under project bar. To use a [class] library from another project, first build the library project; this gets you a Dll. In the client application, use "Add Reference" to get at the Dll. The [public] class/properties/methods in your library should now be accessible in your client application. HTH, Phill W. >> i have Created one class project and one client project (2 separate >> solutions) [quoted text clipped - 10 lines] > HTH, > Phill W. I usually find it more convienient to add the library project to my solution, and then reference the project.  SignatureTom Shelton Hi Tom, "Tom Shelton" <tom_shelton@YOUKNOWTHEDRILLcomcast.net> wrote in message > I usually find it more convienient to add the library project to my > solution, and then reference the project. With large solutions, that can cause IDE performance issues if you make edits to the library. VS 2008 is better (not perfect) in that regard than earlier versions. I still prefer to have an assemblies folder that each project does it's build to, and reference the assemblies from there rather than referencing projects. Downside of that is you don't see cascading changes until you do a rebuild. In Class project, I have used 'build Solution' from menu bar. In Client project, I tried 'browse' option,too. But it does not show class name untill physically added. ( file type: component files) What is the way to generate DLL? Rachana > In Class project, I have used 'build Solution' from menu bar. > In Client project, I tried 'browse' option,too. [quoted text clipped - 4 lines] > > Rachana If you have built the Class Library solution, then there will be a .dll in the bin folder for that project. In your client application, choose Add Reference and then browse to the .dll that was produced. Chris > Hi Tom, > [quoted text clipped - 9 lines] > than referencing projects. Downside of that is you don't see cascading > changes until you do a rebuild. Is the performance thing you talk about a VB.NET issue? Because I don't recall seeing any problems with this in C# - but I guess it depends on what you mean by large solutions? The largest I worked on had about 50 some odd projects in the solution - and other then initial load time, I didn't have many problems with the ide. There are valid times of course to use file references - especially when you are working in teams, but for most of my personal stuff I like project references :) SignatureTom Shelton >> Hi Tom, >> [quoted text clipped - 16 lines] > some odd projects in the solution - and other then initial load time, I > didn't have many problems with the ide. Right. Becuase VB6 does a backgroung compile, when you make a change somewhere, those changes cascade through the entire project. Sometimes that cascading can really slow things down, but as I said, VS 2008 is a lot better than previous releases. By referencing assemblies toher than projects, VB has the same behaviour as C# -> you have to compile for any changes to propagate up the chain. > There are valid times of course to use file references - especially when > you are working in teams, but for most of my personal stuff I like > project references :) Sure, with small projects this isn't likely to be an issue. > I usually find it more convienient to add the library project to my > solution, and then reference the project. Many of my libraries wind up in the Global Assembly Cache and I find it considerably easier (and more reliable) to test GAC-registered code when it's been loaded from the GAC. Removing or changing references, accidentally getting Local copies of assemblies that cause incompatibilities, duplicate definitions or other weirdness and are (or used to be, anyway) a damned nuisance to get rid of, inadvertently changing the code you only meant to step though, so it that everything /works/ on your machine and not on anyone else's where they've still got the "real" code, having to remember to change everything back again when you're done ... IMHO, it's just not worth the hassle. YMMV. Regards, Phill W. Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.