I have been working with Visual Paradigm for a while not and I love the tool. The only thing I get annoyed by is the amount of files it generates for each project.
The files I mean are <project name>.vpp.bak_<number> and <project name>.vux.
Is there a way to store them somewhere else (like a subdirectory) or delete them automatically?
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.
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.
My program adds files to a VB.NET solution. What I want is that the project, when files are added to it, is refreshes or prompted to refresh. Now what I am currently doing is unloading and reloading the project. This is fine, but I noticed that my newly added files are not included in the project, and I have to manually include them by clicking them.
How can I make my project add all files that are not included and refresh when new ones are added?
Thanks
My code to add.
A lot of files can exist in folders and subfolders under the solution (sln file). not all of these files are required to participate in projects. each project file (vbproj / csproj) maintains the inventory of files included in the project. you need to both place your files at appropriate places and update the vbproj file appropriately.
As it happens, the vbproj files are not simple indexes, they are full blown build scripts. they have a pretty intricate file format (XML) and a convoluted semantics. Appending nodes in that file works fine if you follow the existing pattern. but i suggest you look up MSBUILD first.
Please note that if the project you are mutating programmatically, is open in visual studio, then there are strong chances of inconsistency. make sure the project is not open in any visual studio. programmatically altering the program itself (or the same project) is not advisable.
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