I have a project in c# which is represent a Ground Station for Aircraft.
I need functionality that when I click on save test, then there is a new project same as the Ground station will be created.
simply just like the visual studio project there is a button to create new project, which is same as visual project.
in other word, I need to create new project from same project with customized configuration.
How to do that?
Do you mean how to create an exact copy of the project you're currently working on?
If so, I'm not sure there's an automated way to accomplish this, but you can just go into Documents\Visual Studio %YourYear%\Projects\%YourProject%, where you replace both of the %-delimited values with your local values. Then, just copy your entire project folder, give it a new name, and open the solution therein. You'll be able to edit it as you see fit without changing the original version.
However, I think you'd be better off using some sort of version control system, like Git or Subversion. With either of these, you can create branches off your master version. You can effect whatever changes you like with these branches without affecting any changes to the original master. If you decide the changes you've made on any branch are worth keeping, you can merge some or all of them with the master and create a new master version.
Related
I have a .net mvc site that should be published to a lot of different customers, and thus vary slightly depending on the target.
Is there any way to set up the core project structure, e.g. (simplified):
views
models
controllers
assets
bin
and make a merge at build time with whatever variations the current target might have. For example:
core project:
views
view1.cshtml
view2.cshtml
(removed rest of the folders for brevity)
customer 1 target:
views
view2.cshtml
view3.cshtml
desired merge result:
views
view1.cshtml (from core project)
view2.cshtml (from customer 1 target)
view3.cshtml (from customer 1 target)
The same rule should apply to controllers, binaries etc.
I would either use multiple projects, nuget, or use source control. I will talk about these ideas below, but in no particular order. By the end I may include a preference towards one or the other.
First idea I'll talk about is to use multiple projects. Create your base project, let's call it WebBase. Create your core website that you have talked about. Next create Customer1 website, if you create Customer1 as an empty website you will need to recreate the folder structures in WebBase or you cane create it the same as you did with WebBase and remove all the files(do this from within Visual Studio); either way you end up with the folder structure with no files. I would recommend keeping web.config,packages.config, Properties folder with AssemblyInfo.cs. Then you will add the files from WebBase, but don't just add them normally. For illustration's purpose let's do the Home Index View: Expand the Views Folder in Customer1, Right click on home, choose add, choose Exising Item, browse out of Customer1 and then in to WebBase/Views/Home and single click index.cshtml, now notice the drop down on the button? click that and choose "Add as Link". Now do this for all the files in WebBase! It will seem cumbersome to choose "add as link" every time, but if you just click add, it will copy the file and updates won't propagate from WebBase to Customer1! Also, you will see things like remove from project vs delete (with prompt about permanent deletion).
Second thought would be to create a nuget package for WebBase and you can than install it as a package, the benefit of this approach would be versioning and it would not require you to update every project with each little change. It would keep each project completely isolated. Down side is you would need to update each project individually to propagate changes globally. You would need to learn about nuget's nuspec file and how to include files and such. It isn't that bad, it is just XML. But you can indicate which files to include when the package is installed/updated.
Third would be source control, I know with git you can use submodule to include a seperate project (even from external repository). Which might be an option, or you could just create a WebBase branch, setup WebBase and then branch it off into each Customer's website. So create a branch called Customer1, start adding the custom customer things. Switch back to WebBase, create a new branch called Customer2... you are off to the races. Switch back to WebBase, make a global change and then merge these changes into Customer1 and Customer2 branches.
Okay, I will admit it, I would probably go with the third option. It gives you lots of benefit with little downside. It even get gives you history! If you aren't currently using source control... you should! You can install git on your machine and have the ability to check code in locally and you don't have to worry about an external repository (although I would recommend you have one as it gives you DR).
Either way, there are options available. But nothing like a single project with configurable file includes.
Good luck!
First thing that comes in mind (and probably easiest because it does not require any additional tooling) is to create core project with core functionality, views and controllers. And for each customer create separate project with custom views and controllers. Then for customer-specific project simply link all required files from core project. It can be a little tedious to link the files depending on the number, but seems doable.
Another approach could be to use tools like CAKE or FAKE, with the help of which you can script the entire build process the way you want, but I never tried doing such custom scripting myself.
Third option that I can work as well is to conditionally include files based on defined constant, but that will require editing *.csproj files. The code can be something like:
<Content Include="Views\View1.cshtml" />
<Content Include="Views\View2.cshtml" Condition="$(DefineConstants.Contains('CORE'))" />
<Content Include="Views\View2.cshtml" Condition="$(DefineConstants.Contains('CUSTOMER1'))" />
<Content Include="Views\View3.cshtml" Condition="$(DefineConstants.Contains('CORE'))" />
<Content Include="Views\View3.cshtml" Condition="$(DefineConstants.Contains('CUSTOMER1'))" />
Not sure how easy it will be to maintain it though.
I would probably consider to split the application into independent components/projects that will contain all functionality related to the component. The during the build compose components with FAKE based on what components are needed for particular client.
Your requirement is a great candidate for a custom Visual Studio Project Template.
I am thinking of preparing one big project with all the features you're deploying to whatever customer. This project also could be the trunk that you might update when a new feature or a fix is needed. Then, export the trunk-solution into a template. Then continue with VSIX project template and incorporate a wizard into it, to collect user input on a project creation. Based on the input take the appropriate action and add/remove the necessary files or enable/disable features as needed.
Or you might just keep the source files on the file system and organize them into the template on the fly - i.e., as a result of the user input during the wizard. At the end of the wizard, the template is deployed and ... voila.
What you need is super-admin section, where you could [de]activate different portions of the site, depending on customer.
There are some really good code answers here but if you're wanting an Automated Build system for every client and you have loads they could be a pain too setup.
When you could set up a script for Powershell that can do this
pseudo code
For each client site
download base code to code/
download this client's changes to code/ overwriting files
msbuild ....
copy client/ bin to build/client/
Delete code/
End For each
The answer to this question requires some innovation. So look at my solution please:
Set up the core project structure for the classes that cover Model and Controller files and then use them with technique named Add Existing Item As a Link which can share the followings:
App logic common to both apps, but not portable
User controls with no platform dependencies
Unfortunately that is not supported for razor views. So the easiest thing to copy shared views is to have multiple layout files like famous _Layout.cshtml file, one in each web app. You can also Compile your asp.net mvc Razor views into a separate dll to use them like a Reference (as shared views).
For the Assets, You can host all your style sheets (and some javascript if appropriate) from your main web application and access it from each web app.
The bin folder has core MVC dll files plus those that you add for using in your project and a projectName.dll file which will be created after building. You can simply Add/remove them by right clicking on References using Add Reference tool.
Suppose I have a team project in tfs and every time I check in, a new build takes place. Now what I want is that suppose I add a class library to the solution then when I build it a new dll is formed for the class library. So when I check in I want the tfs to just copy only what wasn't there before in the server, i.e.. the class library dll not the whole project again.
Is this possible and how to do this
If you don't add the class library to the version control, it will not be checked in. If it is added by default, you can exclude it when you check in. (in other words, you can always select and add to the source control workspace)
So, you have a TFS 2013 server with a continuous integration build? And you want to set the CI build to be an incremental build?
Assuming you are using the TfvcTemplate.12.xaml build template, then in your build definition you should check out:
Clean Workspace [true/false] which controls whether the build agent pulls down all the code again or only things that have changed.
Clean Build [true/false] which controls if everything is built again or only things that are new (like your class library). This setting only takes effect if Clean Workspace is set to false.
More details
My situation:
I have a solution A with hundreds of projects,
Some of projects are class libraries and are referenced from other projects.
Now I want to create a new solution B which will consist of subset of projects of solution A. I start by adding the first pre-existing project into this new solution B. This project is referencing couple of class libraries from solution A. Therefore it is logical that these libraries cannot be found and I cannot build. Of course I could add all the referenced projects manually into the new solution B but that would take quite a long time, considering the total amount of projects that I need to add.
Is there some built in Visual Studio feature that can take care of this on my behalf? I.e. I will be offered an opportunity to import all the referenced projects at once and the B.sln file will be updated automatically.
I also have a ReSharper extension but I couldn't find such feature in there as well.
EDIT:
Some more detail on what I am trying to achieve. A.sln has lots of application projects and literally hundreds of class libraries. I want to create a new B.sln for one particular application project from A.sln and only add the class libraries that it is referencing, directly or indirectly... But the dependencies can go up to 15 levels deep so manually removing projects from original A.sln to create B.sln is really not suitable for me as I would have to carefully consider each one of the projects that I would be manually removing from the original sln file, subsequently reviewing the csproj files to find whether the application I am interested in does not indirectly depends on them via one of its direct references.
Copy paste your current solution file and start with it. Open it in new Visual Studio Instance. Remove your projects one by one. Instead of adding new projects, removing unnecessary ones will be more easy for you. As far as I know there is no such feature in Visual Studio as you want.
Removing will be more easy since projects are already there. Do not use Visual Studio to remove project but open sln file in suitable programmers notepad. Your projects are added to sln file as below lines.
Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "Example.Integration.App1", "..\Example.Integration\Example.Integration.App1\Example.Integration.App1.csproj", "{E3977144-AFBA-451D-894C-1F89AA008041}"
EndProject
Removing such lines will be more easy if your projects has naming convention.
The best way to port references from an existing project that I've found is to generate a template for that project.
On the File menu, click Export Template. The Export Template wizard opens.
Choose project template and move through the wizard
Click Finish. Your project is exported into a .zip file and placed in the specified output location, and, if selected, imported into Visual Studio.
Now, when you setup a new project for solution B. You'll be able to choose the project template from A and all the file structure/references are preserved.
Ref: http://msdn.microsoft.com/en-us/library/vstudio/xkh1wxd8%28v=vs.100%29.aspx
I have a Visual Studio 2010 solution with many projects and many build configurations in order to make use of Web.config transformations for automatic deployments.
My problem is when a new project is added it does not inherit the existing configurations and thus the build fails on the build server.
As an example, say I have the following custom build configurations:
Development
QA
Production
When a new project is added, it only contains the standard Debug and Release configurations and none of the above custom configs.
The only way I know how to fix it is to manually edit the .csproj file.
What is the proper way to handle this?
Edit I have removed the information about why it fails on the build server because that is irrelevant (and obvious), I just need to know if there is a way to have existing custom build configurations automatically picked up by a new project being added to the solution.
The proper way to handle something you have to do manually on a computer is, usually, doing it automatically. No kidding. All our project files (both C# and C++) are generated: they automatically import the correct property sheets with all build options and all have the same platforms/configurations. It's a relative small amount of work to throw together a program that will save you much more time and effort later on. Basically the Microsoft.Build.Construction namespace has everything you need. To make the program user-friendly we added a small ui on top that lets you drag in directories in which to create projects. So we just run it, create a directory, drag it onto it and add the new project to the solution in VS.
I have a solution in visual studio where one project (.csproj) is set to create an exe.
I would need to create a duplicate copy of this project so that I can name it something different and change the icon for it. (All of the rest of the projects can stay the same)
I am using conditional compilation symbols for that project, but I don't want to create a whole separate solution configuration because that requires expensive rebuilding of the entire solution.
In Visual Studio under Build -> Configuration Manager, you can create a new configuration for your project and clone it from your release build, then in your project properties you can customize it.
For the icon, you'll want to refer to Set a different ApplicationIcon for each build configuration
Create a copy of the project on disk (outside Visual Studio) and add the copied project to the solution. Then you can modify output assembly name, icon. etc..
However better practice would be to perform the necessary operations as postbuild step (e.g. batch/powershell script) as you will have to keep the projects synchronized (added/renamed/removed files, references...)
Copy it somewhere else and change the assembly name and namespace may be on the project property window( right click and property)
I dont know what your trying to accompish but possible solutions:
add post build event that will copy exe / (exe ad dll-s) to another directory
if you use TFS, edit your Build so it will create copys
Cheerz,