Toggle project (enterprise software) features at build.

So right to it. Is there a feature in Visual Studios (or one of it's project templates) that will allow me to build a single project that'll gives me the control of toggle certain features on and off? I'm reluctant to build the project with an initial method called before it starts that goes through and "hides" these feature (my only idea). But rather I'd like to remove them all together at the build/publishing step - which I can see being a prevention measure that stops the user from hacking my software and turning them on manually.



I know it sounds terrible, but at the moment I actually have more than one of the same project going on. Each having identical core functionality, but differ only by specific functionality per requested.

And yes. It's by far the most frustrating process to deal with day to day.



I am in Visual Basic, but if you can suggest code in another language then that's fine. I'm positive I'll be able to understand it.

see if this is of any help....
http://msdn.microsoft.com/en-us/library/tx6yas69.aspx

Just be careful that if you block out something you aren't calling it from somewhere else...

-tg

Hmm thanks techgnome! I using these quite often for debugging/developing vs release. But I haven't even once considered their use here.

Another question, could there be issues wrapping them around entire objects? I wanted to extend this to forms, and maybe even the crystal reports - so that they're not included themselves in the packages they don't belong to.

There could be issues. If you have object Foo excluded from the project, then you must be sure you aren't referencing or creating an instance of Foo somewhere else, because the type will no longer be defined. It seems likely that if you have a type Foo, then at some point you are probably using type Foo, so it seems like it might be hard to disentangle a type out of a project, but you would know that better than anyone else.

Seems to me it makes more sense to build the functionality into separate assemblies and use them in a plug-in style...

-tg

Quote:

---

Originally Posted by Shaggy Hiker

There could be issues. If you have object Foo excluded from the project, then you must be sure you aren't referencing or creating an instance of Foo somewhere else, because the type will no longer be defined. It seems likely that if you have a type Foo, then at some point you are probably using type Foo, so it seems like it might be hard to disentangle a type out of a project, but you would know that better than anyone else.

---

Exactly what I thought.. It's going to be impossible to judge now, but I can see it being an inevitably truth throughout the development life cycle of this project.

Quote:

---

Originally Posted by techgnome

Seems to me it makes more sense to build the functionality into separate assemblies and use them in a plug-in style...

-tg

---

This sounds like a good idea, but I've never, ever attempted such a task. It's always been in thought, but always fell to the wayside after another solution. One that's usually much less complex.

Where should I begin? I'm not even sure of that. I'll do some research myself while I wait for some responds, and if I get there first I'll post what I'm able to accurately gather.

I'm currently working on a plug in project. It takes a certain amount of thought starting up. I wouldn't go into it lightly, but I would go into it. Frankly, you will learn some simple and interesting things along the way.

Making a plug-in system work by hand isn't difficult. I think that MS has also provided some kind of library, or something, that is supposed to make it easier, but it isn't hard to do the code anyways. What I did was think about what kind of functionality would be common to all the plugins. I put that functionality into an interface in a class library project. Every plugin, along with the main program, referenced this common class library. That way, every plugin could have whatever types it wanted, so long as it had at least one type that implemented the interface (or you can have many interfaces, as I have now ended up with). This works because every object that implements an interface can be used as that interface as if the interface was, itself, a type.

In the main project, you use reflection to examine the objects in the plugin (which is also a class library), and create instances of any that implement the interface, as needed. I believe this might be a relatively slow process, in which case there are probably several ways to speed it up. In my case, the program makes one of every type of object it finds, but that's just because of how the design works.

The only real code to it is that part about the reflection in the main project, and that's only a few lines, in practice. I've posted a couple examples of it around here at times. The difficulty is entirely in figuring out what belongs in the interface. That makes you think about general categories of interacting with the objects. Therefore, the bulk of the difficulty lies in design and not in execution, which is a bit unusual.

Quote:

---

Originally Posted by DavesChillaxin

I know it sounds terrible, but at the moment I actually have more than one of the same project going on. Each having identical core functionality, but differ only by specific functionality per requested.

---

Or, wrap up the "core functionality" into a library that you can share across multiple projects?