I currently have two MVC projects in two solutions which will share a fair bit of look and feel but very different functionality. As such they have different solutions to manage their code. Everything is being stored in TFS repositories.
Currently any shared C# code is managed through class libraries and while this is great for the C# code there doesn't appear to be a similar way to do this for JavaScript or CSS files. Is there a best practices way to handle shared JS and CSS files between separate solutions in TFS specifically or just in solution files in general?
To be clear what I mean when I say "shared," it should have the following criteria:
File has the same name in both solutions.
Editing the file in solution A results in those changes being applied to that file in solution B.
Ideally this will be transparent to the developer.
You can create a separate project (say "CommonJsCss") that contains all of the shared .js and .css files. Then just include that project in both Solution A and Solution B.
why don´t you put your files in a folder, let´s say 'c:\myprojects\shared\javascripts'
and include the folder in all the solutions you need it to be?
all code changes will be usable for the other project. Also, you can define your own bundles in each solution including those files.
Related
I'm quite new to C# and Unity so have mercy on me. I'm using visual studio.
I have what seems like a pretty common problem. Which is - i want to use functions i write across several projects in unity. I don't want to have to go search for the code in some folder, copy paste it into the new project, or fiddle with symbolic links or use .dll's. These are all not great solutions to the problem. Can't i just somehow create a class I can access across all my projects? Custom namespace perhaps that is not project specific? that i can simply just call at the beginning of wherever i want to use my homemade scripts.
If you don't want to build a custom DLL and the headache that comes with maintaining its versioning alongside Unity releases, consider building an AssetPackage. You can right-click in one of your projects and export a bunch of scripts that you want to be re-used in other places together as a package. When you start a new project, just load that package into it by dragging and dropping it.
If you're using git for your projects, you could add the shared code into a separate repository and add them to your projects as a git submodule.
You have 2-3 things to consider in this situation:
Ease of deployment
Whether or not you will update that code
Ease of update, if you will update it
If you just want to bring it in once, then Erik's answer should be simple enough.
If you want to keep things as an updated library though, you will need another method.
Symbolic links as you mentioned would be the best, or DLLs. However, with this, you'd run the risk of breaking your other projects if you ever modify the common lib from inside your project.
Another option would be to have a separate VCS (git, svn, etc) inside your project for your common code. This way you can update if/when you want, you can roll-back if something breaks, and you can even fork your "common" code to make a project specific change.
Since OP mentioned it, in this case, OP could specifically use Git Submodules or simply add a second Git project and add that sub-Git to the parent's .gitignore file
I have a few classes that are abstracted in a way that I can use them in multiple projects. I'm always working on these classes, optimizing, adding, etc. So when I optimize something in one of these classes, I then need to copy that new version into every project I remember using it. This isn't a very good way of doing it, but is there a better way?
Thanks
Put these base classes in a single project and share this project between your different solutions as an referenced class library. This way you will not have to copy / paste anything between projects or solutions and everything should always be up to date.
You could even set-up a local NuGet feed so you can use NuGet to retrieve this shared project as a reference in a well structured and managed way.
Instead of manually copying the updated classes to every project that uses them, create a Class Library project and reference the compiled file in every project that uses the classes. Organizing your classes like that will help you to follow the DRY ("Don't repeat yourself") principle.
If you need to reference files instead of compiled libraries, however, you can reference a file as a link so that multiple projects refer to the same file without copying it to each solution folder. To do that, right-click on your project, choose Add existing item..., browse to the .cs file, and choose Add as Link from the combobox in the right lower corner.
How about if you extract the classes into a separate project, and add a reference to this project in every project you are using?
It is a bad idea to copy paste file throughout the application. To avoid these repetitions you can either:
make a link, if the amount of file is really small . In the Solution browser of Visual Studio, right click, Add Existing file, chose your file and in the split button, choose Add as a link
create a separate project and reference this project wherever is is necessary if the amount of files not tiny.
Create a base-lib and build it to a "shared" location. Add a reference to it in you project. It will keep the other projects smaller and will be faster to build.
I realize that this is not the best practices for working on individual projects. However, I had a rather large code base I am attempting to refactor, and would like to know if a change I make has modified/broken any number of existing projects.
Is there a way to add all existing projects within a specific directory to a single solution within visual studio?
If not, is there another way I could do this without manually adding each project?
I do not believe there is a method in the box.
But if it's really going to be that tedious of a task I would use PowerShell to search the directory for a files with the csproj extension, and output a bunch of "Project" statements (along with generation of unique identifiers) that you can copy/paste into your Solution file.
I've currently got a solution where a certain class is used from several C# projects, some Silverlight, some regular. For compatibility reasons I cannot create a single project for these utility classes. At first I solved the problem by making the class library project a silverlight one, so that it could be referenced by all other projects.
However, I ran into another problem that made it impossible to use a Silverlight project as the class library. So I resorted to making two separate class library projects: one Silverlight, one regular. In C++ it's possible to add a project file to two projects, while only having one physical file on disk. I noticed that in C#, it automatically makes a copy when adding the file to a second project. I solved this with a build event that copies the file from the regular library to the Silverlight one when the Silverlight project is built.
This all works, so technically the problem is solved. However, it's gotten too convoluted for my taste. Also, other programmers who are unaware of my solution might start to edit the dependent (Silverlight) file, and get unexpected results.
So my question is, do you know of any good reasons to solve these two issues properly? How would you solve it?
If you need 1 file on disk do not use the standard "Add" when adding the file to your project but click on the arrow next to it in the dialog and select "Add as link", however this does not prevent it from being edited (you'll have to look into other options there, I'm not aware of any)
I think you are talking about linking. Have a look here:
http://support.microsoft.com/kb/306234
Hope this helps.
have the file in one project then in the other projects where you want to have it as well do Add Existing Item, select the file and see the Add button in the dialog has a small arrow, select Add as Link from there and you are set. :)
Honestly, I can't word my question any better without describing it.
I have a base project (with all its glory, dlls, resources etc) which is a CMS.
I need to use this project as a base for othe custom bake projects.
This base project is to be maintained and updated among all custom bake projects.
I use subversion (Collabnet and Tortise SVN)
I have two questions:
1 - Can I use subversion to share the base project among other projects
What I mean here is can I "Checkout" the base project into another "Checked Out" project and have both update and commit seperatley. So, to paint a picture, let's say I am working on a custom project and I modify the core/base prject in some way (which I know will suit the others) can I then commit those changes and upon doing so when I update the base project in the other "Checked out" resources will it pull the changes? In short, I would like not to have to manually deploy updated core files whenever I make changes into each seperate project.
2 - If I create a custom file (let's say an webcontrol or aspx page etc) can I have it compile seperatley from the base project
Another tricky one to explain. When I publish my web application it creates DLLs based on the namespaces of projects attached to it. So I may have a number of DLLs including the "Website's" namespace DLL, which could simply be website. I want to be able to make a seperate, custom, control which does not compile into those DLLs as the custom files should not rely on those DLLS to run. Is it as simple to set a seperate namespace for those files like CustomFiles.ProjectName for example?
Think of the whole idea as adding modules to the .NET project, I don't want the module's code in any of the core DLLs but I do need for module to be able to access the core dlls.
(There is no need for the core project to access the module code as it should be one way only in theory, though I reckon it woould not be possible anyway without using JSON/SOAP or something like that, maybe I am wrong.)
I want to create a pluggable environment much like that of Joomla/Wordpress as since PHP generally doesn't have to be compiled first I see this is the reason why all this is possible/easy. The idea is to allow pluggable themes, modules etc etc.
(I haven't tried simply adding .NET themes after compile/publish but I am assuming this is possible anyway? OR does the compiler need to reference items in the files?)
UPDATE (16/05/2010):
I posted a similar question with a little more detail for question 2 on Experts-Exchange. I don't want to post all that info here as it just will be too messy but it explains question 2 in greater detail.
For your first question, you want to use svn externals. More details can be found here: http://svnbook.red-bean.com/en/1.0/ch07s03.html
For your second question, you need to create a seperate assembly and the easiest way is to create a new project within your solution. You can't have a single project emit 2 dll's (that I know of)
For your first question:
If the base project is a library then there is nothing stopping you from creating the following directory structure on your SVN:
Base project
Cool project nr 1
Cool project nr 2
All projects built on the Base project will include a relative reference and then everybody can checkout his Cool project X and the Base project and work on them. Checking-in changes for Base project will allow everybody else to see them by updating their Base project image. Advantage: only one SVN trunk required.
For your second question :
I tried my best, but I can't understand what you're asking :).