[RESOLVED] namespace, folders, deployment
What I want is a single folder, in it a folder for program 1, a folder for program 2, a folder for the dll and a serialized list that all three can access
How does one go about setting up a collection of folders to get the same namespace for a dll and two separate programs? I tried creating a project for each but, that creates with it completely different namespaces and separate folders. As far as I can see vb doesn't let you save the dll and two programs in the same folder - without a ridiculous number of same - namefolders two levels deep. Making it impossible to know where things really are. A solution is a group of projects - but how can you deploy anything but a single project?
I have tried cutting and pasting my code into a variety of best guess scenarios and none it really brings me any closer to getting this figured out.
Remember the good old days when a file didn't have anything you didn't put in it or you could actually be productive without a mammoth amount of overhead or garbage?
OR have this site log you off before finishing a post....
Re: namespace, folders, deployment
If you're using ClickOnce then you're basically out of luck with regards to what you want to do. ClickOnce is designed to work at the project level, i.e. you publish a project and a ClickOnce installer is created for the application. If you want to do something that ClickOnce can't do then you can't use ClickOnce, plain and simple.
If you're using VB Express then ClickOnce is the only deployment option built into the IDE. If you have a full edition of VS then you can create a Setup project, which gives you full control over what goes where and including output from multiple projects is no issue. I'm not sure all do but some editions of VS also provide InstallShield LE, which I haven't used yet but probably gives a few more options again over a Setup project.
Re: namespace, folders, deployment
I'm going to address the "How do I get them in the same namespace" issue and ignore any deployment issues; I'm not sure if it was on-topic and I don't have any experience with ClickOnce anyway.
VB .NET treats developers like babies in many ways. It hides some of the guts of how .NET is implemented, presumably because someone decided VB developers aren't smart enough to understand it. (OK, fine, it's because 90% of the time you don't care and don't need to deal with the detail. But because it's hidden away, it's hard to know you can customize it.)
In your project properties, you should see a "Root Namespace" field on the "Application" tab. This represents the namespace for a folder-less file in the application. Let's say you have this project directory structure:
Code:
Project
|--Utilities
| |---SomeClass.vb
|--Folderless.vb
Now let's say your root namespace is "Root". The fully qualified name of each class in this example will be:
- Root.Folderless
- Root.SomeClass
This kind of surprised me; I swear sometimes I see folders add a namespace. I think I'm getting confused with C#.
So what if you wanted SomeClass to be "Root.Utilities.SomeClass"? You'd make sure to specify a namespace:
Code:
Namespace Utilities
Public Class SomeClass
End Class
End Namespace
In VB .NET, when you specify a namespace, the root namespace is prepended to the one you specify. If you used "Namespace Root.Utilities", the namespace would really be "Root.Root.Utilities"; suboptimal. I believe C# ignores the root namespace if it isn't part of the namespace specified in a statement. Anyway, this is all well and good if you don't mind making the root namespace the same for all of your projects *or* you don't need two completely different namespaces in one assembly (which is legal.)
So let's say you wanted "Root.Folderless" and "NMinusOne.Utilities.SomeClass". How would you pull that off? They have a different root so you're hosed, right? Wrong. This is kind of weird. You can tell Visual Studio "I don't want a root namespace" by changing the root namespace to be blank. When you do this, you have to specify a namespace for *every* class in your project or else they will end up in some kind of weird global namespace. So you'd have to have two code files:
Code:
Namespace Root.Folderless
Public Class Folderless
End Class
End Namespace
Code:
Namespace NMinusOne.Utilities
Public Class SomeClass
End Class
End Namespace
It's a pain in the butt, and I really prefer how C# handles it since the auto-generated namespaces are sufficient 99% of the time, but I guess there's an argument for keeping the indentation level down a notch.
Re: namespace, folders, deployment
Thanks. Wow, ok.
I have one program and the dll with the same namespace but in my second program (after cutting and pasting it from the original attempt) I'm getting errors about events, like
Code:
Error 3 'Text' is not a member of 'EventDisplaySolution.frmDisplay'. D:\VB2008 Programs\Event Display Solution\Event Display\Event Display\frmDisplay.vb 45 9 Event Display
EventDisplaySolution <= is the namespace for all 3 programs
frmDisplay <= is the assembly name of the programs with errors that has a EventDisplaySolution namespace.
hmmm, any ideas short of dumping the entire code in the post?
Re: namespace, folders, deployment
Thank you Sitten Spynne and jmcilhinney for your advice. I did finally get it to work. This was a trial project into the world of VS2010. I will not be buying the full blown version. Why waste money and time.
I regret starting this endevour. The simple task of creating, reading and writing a file has taken too much of my life. Let alone the two plus hours trying to get it to run as a scheduled task. I am convinced that Microsoft has been infiltrated by people who want to take it down and they are succeeding masterfully. There are many languages, many of them web-based, that will do the job far faster and simpler than this overly complicated language. Windows 7, .NET, Visual Studio, Office 2010, all of Microsoft's latest products have thoroughly convinced me they are taking my money and wasting my time, with the mandate change for change sake. Release a new version, spend more money - well not anymore.
Re: [RESOLVED] namespace, folders, deployment
Create and write a file:
vb.net Code:
IO.File.WriteAllText("file path here", "Hello World")
Read a file:
vb.net Code:
MessageBox.Show(IO.File.ReadAllText("file path here"))
Maybe you have wasted some time, but I don;t think that it's because the language is overly complicated.
Re: [RESOLVED] namespace, folders, deployment
I'm going to be frank. Feelings might get hurt. It happens.
I don't think Microsoft made a convoluted programming language, I think you overengineered the solution to a problem. It's relatively difficult to write three different applications that share namespaces and types in any programming language. But the simple task of creating, reading, and writing a file involves less than 10 lines of code even if you do it the long way. What the heck do you need three applications for? It's like you're complaining that it's hard to drive a car while juggling.
I have a feeling you're asking a bad question because I see symptoms of a pattern that springs up often. Instead of asking, "How do I solve this problem?", you have decided on a solution to your problem and are asking "With no other context, how do I write code that does this?" Sometimes this works by coincidence, but most of the time it doesn't. Here's how the conversations almost always tend to go:
Quote:
X: I need to know how to use a hammer.
Y: Ahh, that's easy. Hold the handle (the part that doesn't have a large heavy object) tightly in one hand and strike the nail with the heavy end until it's all the way in the wood.
X: That's not working, it keeps coming back out after it goes in.
Y: That doesn't sound likely, are you sure you're using a nail?
X: No, I'm using screws. Like I said they go in just fine but they don't stay. Hammers are so stupid!
Y: Use a screwdriver to drive screws. Hammers are for nails.
X: Oh, didn't think of that!
(Or, in amusing cases)
X: Anyone else? This is really urgent and I need to use a hammer!
Asking questions focused on one solution produces answers specific to that one solution and removes the ability for others to suggest an easier course of action. Asking questions that start with the problem, then describe the solution you're trying. That way people are free to tell you you're using a hammer to drive screws. Here's how that conversation goes:
Code:
X: I want to join some pieces of wood with some screws. I've been trying to use a hammer, but it's not working very well. How do I use a hammer with screws?
Y: You don't. Get a screwdriver.
X: Thanks!
I have a feeling the solution you chose may be inappropriate for the problem. I can't comment on that with certainty; all I know is you have 3 applications and you want to read and write a file and this makes no sense to me. Maybe you should start over and explain what you're trying to do, then we might be able to find a solution that doesn't involve using a crane to crush a fly.
