Some time back our group started work on a website project which referenced a DAL project that we housed in the same solution as the website. Since that time we have created some web services, and a couple of client applications that use the same library.
The DAL project still resides in the website solution, and so other solutions have to traverse into the website solutions folder structure to include it.
How are shared projects stored so that they make sense from a multi-solution standpoint? Should my DAL be in its own solution, sitting on equal directory footing with the other solutions that use it, or should it just be a free-floating project that sits outside of a solution folder?
I really want to implement a way that will work when we do this 3 or 4 more times later on because we all know that today's hacked on feature gets 10 flavors requested tomorrow.
Here's how I generally like to set things up:
\Common
\Library1
.csproj and other files for Library1
\Library2
.csproj and other files for Library2
\Services
\ServiceProject1
.csproj and other files for ServiceProject1
.sln which references ServiceProject1.csproj, Library1.csproj, and Library2.csproj
\ServiceProject2
.csproj and other files for ServiceProject2
.sln which references ServiceProject3.csproj, Library1.csproj, and Library2.csproj
\Clients
\WebProject1
.csproj and other files for WebProject1
.sln which references WebProject1.csproj, Library1.csproj, and Library2.csproj
\WinFormsProject1
.csproj and other files for WinFormsProject1
.sln which references WinFormsProject1.csproj, Library1.csproj, and Library2.csproj
AllProjects.sln which references all .csproj files for when you need to do refactorings, architecture diagrams, etc at a global level
Related
I have several .csproj files that I will be importing a common .targets file into, to extend the build process. The projects are in different directories. The .targets file is in the solution directory. How do I refer to the location of the .targets file to import it? There's a solution directory property, but this doesn't work if the developer just builds a project. What do I do? I am using .NET 4.5 and Visual Studio 2015.
As you figured a project doesn't know about a solution it's contained in, and arguably it shouldn't. So there's not much you can do to programmatically figure out where, from the project's point of view, a totally unrelated file is situated. Apart from scanning the entire filesystem for it. There are some alternatives:
rely on a proper directory structure. You do this already anyway, since you use a solution which also needs to find projects in a fixed location. So suppose you have a main project dir with projectA/a.vcxproj, projectB/b.vcxproj and solutionDir/ab.sln and solutionDir/my.targets then in a and b just <Import Project="$(MSBuildProjectDirectory)..\solutionDir\my.targets"/>
require a property (or environment variable) which is set to the location of the targets file and then use <Import Project="$(SomeDir)\my.targets"/>
put your targets file in a 'known' msbuild location like the Importbefore/ImportAfter directories, mentioned here for instance.
I've used all of these at one point and in the end the first is in my opinion the better one: you just have to stick with a directory convention - you need that anyway for projects spanning mulriple directories or with common shared stuff - and that's it. For example we have a ton of common msbuild files and they're in a single repository. Starting a new project always comes down to creating a directory, cloning the common files dir and adding a new project dir. That can it turn easily be automated, also works well on typical CI servers. The second option is also doable, but it relies on a properly setup environment which is less 'self-contained' and gets really messy if developpers start entering the variable in the machines' global environment variable settings, and in the local ones, and so on. Similar problems with the third one but worse since now there's only one correct location.
That Webkit.Net project is great and working fine for me.
https://sourceforge.net/projects/webkitdotnet/
So how could I manage to exclude the dll and other files to separate subfolders? I was thinking about just putting the librarys into subfolder. But somehow I nowhere found a solution that works.
So how can I put the Wekbit.Net into the subfolder webkit.
Here some links I already looked through but not found a solution for vb and win forms:
How to save DLLs in a different folder when compiling in Visual Studio?
C# Putting the required DLLs somewhere other than the root of the output
Copy all files and folders using msbuild
NuGet issues with packages.config, project references and the solutionwide packages folder
http://www.visualmicro.com/page/User-Guide.aspx?doc=Add-Libraries.html
http://msdn.microsoft.com/en-us/library/ms181484.aspx
http://support.microsoft.com/kb/837908
If the Webkit assemblies are neither in the same directory as your application nor in the GAC, you have to tell your program where it can find them.
This answer explains how to resolve assemblies that couldn't been loaded by the CLR: https://stackoverflow.com/a/1373295
I am creating an application which will coordinate and organize a lot of standalone functions. For instance, the main application might be called ABC Company Operations, and within it might be Engineering Bills Of Material and Project Management Purchase Orders, among many others. I want to develop each of these tools as a standalone solution, then include them in the main application when I am done with them. For one thing this will allow me to distribute the main application with a fair number of tools complete, then issue an update when each new one is included, and for another thing having these functions in their own projects will cut down on the madness inside the solution explorer.
Searching and reading have shown me how to include existing projects in a solution, but they are included as a reference - the files continue to reside in the standalone solution. This is not good because I wish to make any changes needed in the standalone, then replace the project in the main solution when those changes are done and also because I would prefer not to have all these solutions hanging around in a public place.
I tried just copying and pasting the project directory from the standalone solution into the main solution, but the solution explorer hasn't picked it up and there are somehow two listings of the standalone in the main Visual Studio screen where you select which solution you will work on. This seems like a bad road, so before I continue down it I would like to ask for any advice you folk may have.
Visual Studio allows you to reference the same project in different solutions.
Right click the solution in the solution explorer > Add > Existing Project...
I have done it and it works perfectly.
But very often referencing the DLL of a class library project is just enough. Usually you would reference the bin\Release version. You can even reference an EXE.
I achieve something like what you want by using the Subversion code management system. I keep each project in a directory. These are top-level directories in the Subversion repository.
Each solution is also a top-level entry in the Subversion repository, but does not have any projects in with it. So I have in my repository something like this:-
project directory
project
files directory
files
project directory
project
files directory
files
single-project-solution directory
single-project solution
single-project-solution directory
single-project-solution
multiple-project solution directory
multiple-project solution
I then use svn:externals to include all the needful project directories when either a single project solution or a multiple project solution is checked out, and it ends up in the working copy like this:-
multiple-project solution directory
multiple-project solution
project directory
project
files directory
files
project directory
project
files directory
files
or
single-project-solution directory
single-project-solution
project directory
project
files directory
files
I have been searching around for an answer to this question, but I cannot find the documentation on it. I found a few similar questions asked here, but none that completely cover it?
Similar Question
What do all of the different files in the project directory do? I am trying to make my project open source and I don't want to have a ton of unnecessary files in my repository. What files are vital and what files will be generated when the user initially loads the project? Its important to note that this is a VB Form Application
Base Directory:
*.vb
*.Designer.vb
*.resx
*.vbproj
*.sln
*.vbproj.user
*.config
Any of the other folders in the base directory?
*/bin
*/Collection
*/My Project
*/obj
*/Resources
*.suo and *.user files can be ignored. They store user specific settings such as window arrangements, open files etc. Those files are generated by Visual Studio whenever a solution is opened.
*.vb files are somewhat important since they contain your source code...
*.sln and *.vbproj files tell Visual Studio which projects are in a solution and which files are in a project, respectively. They also contain project specific settings such as build plattforms, custom build events, target .NET Framework etc.
*.resx and app.config can be important, depending on your project. They should not be left out when you publish your project, however since they're part of the Visual Studio project. If they're truly not needed you can remove them from the project.
Edit
Folders bin and obj are where Visual Studio generates the compiled output so you should not include those when you publish the source code of your project. Any other folders are project specific so it depends on your project if they're needed or not.
As a rule of thumb, anything that is automatically generated should be excluded when you publish your source code.
Also, if you don't already, you should use a version control system such as Subversion or GIT to manage your sources. Any essential files / folders as explained above should go in there.
I am using MSbuild for CI tool and have many C# projects located in different directories. There many dependents projects as well. Some developers use Add Project option to add project and some directly connect to .dll file and i have no control over it. some cases all projects added to a solution So if i compile that solution then it takes care of all dependencies. But i do not this in my auto build. I want to compile all .csproj and output .dlls to a particular folder and then all projects including web should point to this folder for reference.
Want to know if this a ideal process?
In my Project we do the same and it works. Sometimes we have project references and sometimes we have direct dlls references in a folder called "Solution DLLs".
How we do it:
The reason is that we have many projects (120 or more) and we have split them in several solutions. One of the solutions is for framework and commmon dlls. These Dlls are copied in postbuild scripts to a "Solutions Dlls" folder and checked in in TFS. Later our build scripts copy these solutions dlls...
How it works:
It works "fine" and is acceptable. But many problems came (and sometimes still come) with postbuild scripts not working fine. We are aiming to reduce the number of csprojs to 50-60 and use again one single solution.