Maybe this is the wrong question. I don't understand the hierarchy/relationship between solutions and projects, so I'll describe my goal first. I have a forms application which works. I want to copy everything in it to another folder on the same PC with a different name which reflects the purpose of a new forms app I want to build. I want to use the old parent which I copied as a skeleton, a starting point. I've tried copying the whole WindowsFormsApplication1 and renaming it, but when it builds, it refers to stuff in the old parent folder. I want each of these to be totally self contained, not reference something above the new folder I just made with the skeleton.
Can someone describe the relationship between projects, solutions, the folder which gets created called WindowsFormsApplicationx and the .sln file? If this is too general, I'd be happy with just some step-by-steps to accomplish my goal.
Thanks for your patience,
Lamar
Thanks onlinecop, this helps but I’m still not all the way there.
When I created the forms application, it made a set of files and directories in the Studio2010/Projects directory:
WindowsFormsApplication2.sln
WindowsFormsApplication2.suo
WindowsFormsApplication2 (folder)
Bin (folder)
Obj (folder)
Properties (folder)
Form1.cs
Form1.Designer.cs
Form1.resx
Program.cs
WindowsFormsApplication2.csproj
WindowsFormsApplication2.csproj.user
I used Forms Designer to make a presentation layer, which although it doesn’t change much, it does change some.
I want to start with all of these and may or may not make changes to them but I will want to change all of their names.
Besides changing the names, most of my changes are in the Form1.cs and wherever Forms Designer keeps its changes. Since it is a graphical input and not text, I don’t know where it stores its stuff.
I’d like to do this without disturbing anything with the originals.
Almost none are unit tests, and most are new, addressing different applications so I don’t want to depend on a version control tool.
I’d like to not use them by reference, but instead by copy because I want the parents sequestered and unchanged.
So it would seem that I would want these to have completely different solutions, not projects inside of a solution….is this right?
Will the “Add Existing” do this for me, and where should I do it
As I’m reading the tutorials, my impression is that basically a solution is associated with an application and projects are sub-entities which might be incremental changes to host unit tests or debugging.
So since I want to make a completely different application, which I do not want to have confused with the parent, I’m thinking I want a new solution. But I want to use most of what I had in the parent so how can I create a new solution and populate it with the contents of the old source files and rename them? I’d like to not have them called Forms1.cs and WindowsFormsApplication2…..more something descriptive of what they are, like NeutronMigrationAnalysis…
If I’m asking the wrong question, it might become clearer if I understood when I should create a new solution instead of a single one with a gazillion projects in it.
Thanks!
Lamar
A solution contains multiple projects.
Let's say that you create a Unit Test. That test will run methods that you've created in a different project, just to ensure that those methods work correctly. So within this solution, you actually have two projects: one which is your normal forms app, and one that is a Unit Test which you, as a developer, can see but that end users won't.
The folders are merely hierarchal in nature: It helps you keep your projects separate, and files in places easy for you to find.
So take your original forms project, within your master solution. Your solution file (usually a .sln file) defines that you have a single project within it, and the directory where it's stored. It usually keeps track of other general or global information as well.
The forms project contains its own project file (usually a .csproj file), and is usually found within whatever subdirectory it was initially started in. That will define all the files that you want included, all of the special build options, the logical layout of your folders, files, and resources, and so on.
When you want to recreate a skeleton project, you will usually create a new, empty project. Then, copy all of the source files into it from your form project and "Add existing..." the files so they are seen by this project. Doing it this way will prevent the .csproj file from being copied from the original project and keeping all those old parent folder files/references.
Related
Let's suppose I've just compiled my app called "rainbow" (WindowsFormsApp). I'd get the usual "rainbow.exe", "rainbow.exe.config", and also all of the references I used inside the project, like extra DLLs. Is there any way that I can keep the rainbow.exe in a folder, but have all the other files like the references and .config files inside another folder?
For example:
folder\rainbow.exe
folder\extra\rainbow.exe.config
folder\extra\rainbow.dll
folder\extra\something.dll
Yes, but it is QUITE complex because - the references are there to be loaded and if you move them into another folder.... you must interfere with the .NET runtime.
For the folder part: WRITE A SCRIPT - put it into a post build step, done. The app will stop working.
This is how ALL windows applications are working, so nothing unusual here. All of them have all accompanying files in the same folder.
And no, the one you CAN NOT move is the .config - because that is evaluated at start before your code can interfere.
I would say that unless you have some really good reason, you bark up a tree that is totally wrong. One good reason is dynamically loading assemblies i.e. based on parameters at start.
I'm working on a Visual Studio extension that should listen for events when the user adds, removes, or renames files in the current solution.
The answer to this question notes that VS provides infrastructure for listening to document events like saving, opening and closing through the DocumentEvents interface. For example:
Dte.Events.DocumentEvents.DocumentSaved
Are there similar events that would allow me to listen to the user adding/removing/renaming documents?
First, don't use DTE if you can help it. It's a very incomplete, shaky abstraction papered over an extremely complex interface. Having said that, I admit that sometimes it's super handy because the equivalent either can't be done without it (rare) or the alternate code would be quite long (less rare).
There are two concepts being conflated here. The first is the Running Document Table (RDT). The RDT represents all the open files (including the open .sln and project files). You can subscribe to RDT events to be notified of files being opened, closed, renamed, etc. But these events are for open files only!
The second concept is the project system. Each project loaded and displayed in the solution explorer is loaded by the project system for that project's type. C++ projects, C# projects, F# projects, WIX installer projects, etc. all have different project systems. There can even be custom project systems implemented by extensions. It sounds like you want to know about events in the project system, and not events for (just) open files. So your focus is the project system. However, since all project systems have different implementations, this becomes very tricky. VS is moving towards a common project system (CPS), but it's not 100% there yet, and even when it is there remains the problem of all the legacy extensions, etc.
You can subscribe to general "hierarchy" events which all project systems must furnish. They'll tell you for example when a file is added or removed (really, when a hierarchy item (node) is added or removed, since there's not necessarily a correspondence between files and hierarchy items). There's also an event that says the entire hierarchy has been invalidated -- a sort of refresh where you have to discard everything you know about the project and gather up new info.
Rename is probably the hardest thing to detect. Every project system implements it differently. In some project systems, a rename will present itself as a node deletion followed by a node addition, with no solid way to identify that it was due to a rename.
To sum up, nothing is as simple as it seems, particularly when it comes to project systems (one of the least extensible parts of Visual Studio). You'll likely end up with code that is specific to one or a handful of project systems, but won't work universally. (After all, not all projects even represent file hierarchies! And those that do still have folders, special reference nodes, etc. that aren't files.)
Some concrete pointers in the right direction:
Implement IVsSolutionEvents3 to be notified of a project being loaded/unloaded (and IVsSolutionEvents4 to be notified of a project itself being renamed). Register that object as a listener in your package initialization code (make sure your package is loaded before a solution is opened) via the SVsSolution service (cast to IVsSolution and call AdviseSolutionEvents on it).
Implement IVsHierarchyEvents to be notified of project changes like node properties changing (use the __VSHPROPID enum to find out which is which), nodes being added, removed, invalidated, etc. Call AdviseHierarchyEvents on the IVsHierarchy object passed to the IVsSolutionEvents3's OnAfterProjectOpen implementation to register the event listener object.
You can subscribe to the EnvDTE.ProjectsEvents, EnvDTE.ProjectItemsEvents or IVsHierarchyEvents.
I know this is an old post by now, but for anyone else, who is searching for a fast solution. Take a look at the IVsTrackProjectDocuments2 class and it's matching IVsTrackProjectDocumentsEvents2 event interface.
You will receive notifications for all project items (Not solution items!), including Solution Items, which match the following actions:
Rename Directories
Rename Files
Add Directories
Add Files
Remove Directories
Remove Files
SccStatusChanged (I am guessing, that it will fire after a file's source-control state changed.)
These will contain an array of the changed items, their new state and the projects in which updates occurred. Additionally you will get a VS*FLAGS array, which contains more information about the current operation.
I need to make a ClassLibrary, to contain different Resource Files (resx). This needs to be done, so I can reuse these resources on multiple projects.
After reading for quite a while on how to achieve this, I'm still nowhere near close to an answer.
Note that i need to achieve this in a way that I don't have to recompile the proyect if I want to change a value
Is there a simple way to achieve this that I'm missing?
Hate to be the bearer of bad news, but I'm afraid you're trying to use RESX files for something other than what they're designed to do. RESX files are compiled into .resources files, which are then embedded into the assembly during the build. In other words, if you don't recompile, you won't see any changes that are made to the resx file reflected in the module.
The benefits of RESX files extends far beyond providing compiled cultural/language text tightly coupled to a deployed solution. They have the potential to provide a simple and flexible set of content managed outside the software development process. Some views here:
What are the benefits of resource(.resx) files?
Yes you can work with your RESX files without having to compile them. See here:
Edit ASP.NET MVC 3 resx files in deployment server without recompiling
Yes you can share RESX files between different projects and even roll your own resource manager. You can maintain alternate sets of resources, serving up alternate content depending on for example the user context. I have been involved in a project where we implemented something along these lines to great affect, in my case the solution was used to provide white labeling. Some detail to get you started here:
http://msdn.microsoft.com/en-us/library/aa905797.aspx
I have a project, lots of files, lots of work, etc.
It turns out that I can do a few hours of work, and change it into something totally different; but useful for a debug project elsewhere in the shop.
I want to do that, but create a different app; one which uses the same large amount of existing (tested, and working) code, but just changes some buttons and displays and so on.
What's the best way to do this ? Use the OS to just duplicate the entire file structure ? Then hack the thing ?
Should I start a new project and add the same classes until it's duplicated that way ?
Does C# have some sort of an "import and copy" function ?
What OP and I decided on doing in chat:
After a long chat discussion this is what OP and I decided on doing for his code:
Create a new project (in OP's case WinForms) and solution in visual studio by clicking File -> New Project
Import the existing code into the new project by right clicking on the new solution and selecting the option Add -> Existing project and adding the original project OP needed code from
Reference the existing project from the new project by clicking on the references part of the new project in the solution explorer and selecting add reference and then choosing the project OP wanted to get code from
Add using OLD_PROJECT_NAMESPACE; to the top of the code in the new project to have access to methods in the old project namespace.
This provides the following benefits:
Old projects remains unchanged
New projects shares old project's code like OP asked for
A more general answer for code sharing scenarios
You might want to consider making the original program into some sort of more reasonable API. Given that you're using the functionality twice you might do so again. The better thing to do is to extract the classes you'd like to share into a different project and then import it twice, once in the original program and once in the new program.
If you can't do that, here is what I would do:
You're a software shop so I'm assuming you have some form of source control. Most source control programs have some notion of branching your source.
I'd create a new folder, pull the source from the repository and branch it to a different branch.
What you get:
You can easily pull bug fixes from the main branch and thus continue to share code between the projects
You can easily push bug fixes back to the main branch
This is really weird behavior, let's say I have an asp.net mvc project as follow on my desktop (vista):
/mvcapplication/app1
then over the course of development, I copy this solution to a briefcase on a thumbdrive so I can work on it from a laptop (xp).
When I insert the thumbdrive back on the desktop, I notice it's taking longer and longer to sync, eventually it took so long that it just hangs there. I checked the project structure and found that it is now:
/mvcapplication/app1/app1/app1/app1
with each /app1 containing the entire project structures. I am not new to visual studio, and I am sure I opened and saved the solution and files just as I normally did, but this is just bizzard. I thought this is caused by briefcase, but the same thing happened when I copied the solution into a folder on the thumbdrive.
I would have left this alone, but with that sort of crazy folder structure it's really difficult to determine which folder has my current changes..
Anyone ever run into something like this?
Never had this happen but then I don't use the Briefcase. Then again, I try to avoid most things in Vista.
I just use good 'ol copy and past for thumb drive stuff.