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
Related
I am new at C#. I am creating a project that contains two solutions and I cannot reference one from the other. I need to use the classes that are in the AssestManagment to ManejoDeActivos. Is it possible to reference based on the screenshot below?
Reference other Solution
Technically, the project "ManejoDeActivos" is to have only the front end of the applicaction. It has the GUI. The AssestManagment project connects to a database, which will allow to add information to the DB. Inside the "ManejoDeActivos" we have a GUI that allow to add a new asset through a form. I having problems calling the Assest class that will allow to create a new object of an asset. I tried to add AssestManagment to ManejoDeActivos, however when I go to references I do not see the AssestManagment project and if I tried to browse it in my computer the project solution is not showing up
You could take the code needed from one of the solutions/projects, put it into a class library project, and compile it into a DLL. You can then reference that DLL inside of another project and access the code.
I would suggest reading How To Ask to learn how to ask a question properly.
Simplest approach will be to reference all the projects of the old solution on the new solution.
It might be cumbersome as the number of projects increase but would accomplish what I’m thinking you’re trying to accomplish.
I'm not sure how to properly word the title, but here is the situation:
We have a massive solution with about 130 projects in it. There are some redundancies in code, namely a particular LookupButton control we've created. For some reason, instead of being created in the Infrastructure.CommonControls project that all modular projects reference, this LookupButton was created numerous times in the various modules. Quickly poking around through a few of the projects, I found 5 different versions of this control but the only difference is its namespace. All of the code is 100% the same.
I've been tasked with creating one of these LookupButtons in the aforementioned Infrastructure.CommonControls project, and then removing all duplicates from the Module projects.
How can I do this while causing minimal blowback in all of the Designer.cs files that will be looking for MyModule1.LookupButton, MyModule2.LookupButton etc. ? I know I have a backup with SVN but I'm afraid to even start and get inundated with errors...
Easiest thing is to just remove the redundancies from one project, then fix the compile errors in that project until it compiles again.
Push your new code to the SVN and then move on to the next project. There isn't much else you can do.
The following should work:
Ensure you have the current state in SVN
Add the code to Infrastructure.CommonControls
Remove the code from all projects that it does not belong in
Compile the solution
Go through all of the errors. For each occurrence of LookupButton errors, right-click on LookupButton in source control, pick Resolve, and select the option to add a using statement.
You should only find yourself correcting the 5 projects that had their own internal copy of the control, not all 130.
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.
I'm trying to get one of our internal c# click once applications into VSOnline for source control to allow access for an external developer.
I think I've got it set up and working in the Source Control Editor, but am having trouble working through how to actually use the setup day to day.
I've got some git experience but zero TFS experience, but went with the TFS option as I thought it's more likely developers are familiar with it than git.
What I'm trying to achieve is 3 branches; Main/Trunk, Dev and Release and be able to deploy at least Release and Main. Release is for external clients, Main for internal clients.
At the moment my Source Control Explorer looks like;
DefaultCollection
-->Name of project
---->(Branch icon) Dev (created as a Branch from Main)
---->(Branch icon) Main
---->(Branch icon) Release (created as a Branch from Main)
2 things;
In terms of use I'm not really sure how to swap between the branches for coding / making changes? Do I just open the solution file for the branch I want to work on then save all changes as I go, then commit that as a changeset? Or is it a matter of manually checking the file out, working on it, then checking it back in again?
Given it's a ClickOnce app; each branch is deployed to a different IIS site, meaning diff app identies, paths and settings. Am I right in using branches for this or is there a better way? I'm worried about someone committing the wrong file and causing a mandatory uninstall/reinstall of the app.
Any pointers / docco greatly appreciated; just note I'm using VS2010.
Thanks,
Liam
How do I swap between branches
If you're used to GIT than the 'heavy weight' branching in TFVC can be a bit confusing. There is no real "Switching between branches" as you've encountered. You map a branch to a local folder and by opening the files there you're "working on that branch".
As Lee points out you can create separate workspaces for each branch, which will isolate the work areas for each. If you're using a Local Workspace, each workspace gets its own "/tf$" folder, the TFVC equivalent of the "/.git" folder.
There's a couple of documents on MSDN that explain this in a little more detail:
Set up TFVC
Create one or more workspaces
Optimize your workspaces
How do I check in
A changeset in TFVC is the equivalent of a commit in Git, it's a logical set of changed files that is committed/pushed as a whole, or not at all. But just as in Git, you can commit all the changes to your local work area at once, or you can exclude certain changes from the first commit and stick those in a second.
In TFVC you'd normally try to commit a logical set of files that fixed the bug, achieved some goal etc. Though it's still possible to check-out/check-in files individually, chances are much higher that you'll actually cause the sources in the main repository to be in an inconsistent state that way.
See
What is a Changeset
Check in your work
Shelving your work
As for your second question
Depending on how far you'd want to go, you could setup Team Build to actually build the application and to take the configuration from a specific location during the build process. That way you wouldn't have to store the configuration for your production environment with the development settings. Configuration files can contain sensitive information, you might not want to have them in Source Control, except for the development versions.
You can also store the config files in a special folder in each branch and make sure that each time you merge them, they're updated accordingly.
And you can, as Lee mentions, look into Config Transaformations. which apply some XSLT to your config file in the build process. That way you can have multiple config files stored in each branch and the selection of your "Configuration" in Visual Studio will define what the final config looks like.
See:
Tricks with app.config files and click once
The _PublishedApplication Nuget package
SlowCheetah
In terms of use I'm not really sure how to swap between the branches for coding / making changes?
I recommend creating separate workspaces for each branch. This way you won't accidentally check in release code when you are trying to check in dev code. Also, when you want to switch which branch of code you are working on, you switch your workspace. This should keep things "cleaner" and easier to work with.
Do I just open the solution file for the branch I want to work on then save all changes as I go, then commit that as a changeset? Or is it a matter of manually checking the file out, working on it, then checking it back in again?
You shouldn't have to manually check it out. If I remember correctly, it will default to auto check out when you start to make changes. You can check code in however big of chunks as you want. But make sure if you are checking in changes to ClassA.cs that reference needed changes in ClassB.cs, you check that in as well. You don't want to leave the source code in a broken state for the other developers.
If you start working on something and have to suspend that work to do some other task that rose in importance, shelve your work instead of letting your workspace get cluttered up with half done work that makes it difficult to manage check ins.
Given it's a ClickOnce app; each branch is deployed to a different IIS site, meaning diff app identies, paths and settings. Am I right in using branches for this or is there a better way?
I'd look into using web.config transformations for this. You'll still want multiple branches but to separate tested/completed/developing code from each other.
Additional info: I thought it might be helpful to say that my forms and classes are in the same solution as the already updated forms.
In our company we have this project which 3 people are working on it. One works on the database part, me and another colleague of mine are working on making the UI ready and relating it to database which is MS SQL Server 2012 and we are programming in C# in VS 2012.
The problem is that I made this one form ready, but the server version is ahead of me. That is, if I check in the whole program, I will damage the project as some forms has changed and the version I have is older. I tried right clicking and checking in only the forms and classes which I, myself made and I have their latest version. They check in without any error or anything, but the problem is, when my colleagues or myself(after deleting my source project) try to get latest version, my forms or classes doesn't show up.
We also tried to check in the whole program but only accept those pending changes which are made by me, still no success.
The problem is, we are kinda afraid to play with the server version as a lot of effort has gone into it.
Any help will be really appreciated as I'm stuck with this problem and the manager won't give me more parts of the program to make until we can come up with some way to deal with this.
You haven't mentioned merging at all but I think this is the answer to your question.
When you work on an older version of the code (because your local code is older, or maybe the whole branch of the code is older), you need to merge the code into the newer version. When you merge, any potential conflicts are detected and you can resolve all of them manually. There's obviously tools to help you - one is built into Visual Studio but you can replace it with an external tool which may work better for you. Either way, you need to decide how to merge the code. You have a few options:
take the whole code from the source (old code in this case),
take the whole code from the target (new code in this case),
merge the changes and take bits from each version based on your knowledge of the changes and how the code should look like.
As for why the forms don't show up, you probably didn't check in the changes to the project file so the new files are not part of the project as it exists in Team Services.