This is related to How to find a folder with Visual Studio project
I have a SSIS solution in Visual Studio 2012. It has a handful of projects under it, and each project has its own folder. But I renamed the projects within VS. I thought that would rename the directory folders too. It apparently did not. Under my main folder, I have a handful of solutions, and dozens of folders in this one directory.
How do I identify which folder belongs to which project?
Some folders need to be discarded before adding my code to git, and I do need the folder names to match the project names. So I guess I also need to know how to rename the folder (once I identify it), so it matches the project name.
Example - a solution structure:
Solution DIM_Inspect
Project Export_Inspect
Project Extract_InspectType1
Project Extract_InspectType2
Project Load_Inspect
Project Transform_Inspect
And my directory structure (along with a lot of other files and folders)
Dir DIM
Dir Export_InspectType
Dir Export_InspectType1
Dir Export_InspectType2
Dir Extract_InspectType1
Dir Extract_InspectType2
Dir Load_InspectType1
Dir Load_InspectType2
Dir Transform_Inspect
File DIM_Inspect.sln
I can identify the two extracts and the transform directory because they match. But one of those export directories should be called Export_Inspect. One of the load directories should be called Load_Inspect.
(In other words, there was a bit of renaming and figuring things out as I created the solution. Now, how do I figure it out and clean it up?)
Edit
I know all but the last folder for each project. I can look at the files within each folder, and I see my Export_InspectType1 folder has the following files (so it's probably the right folder)
Export_Inspect.dtproj
Export_Inspect.dtproj.user
Export_Inspect.dtsx
Export_Inspections1.database
Export_Inspections1.dtproj.user
Project.params
And the dates for the Export_Inspect.dproj.user indicate an active file (changed today). So I've found the folder (for one project). Is that the only way? And how do I change the folder name (and the .database file name) without messing everything up?
Is the only way to fix this to drop all the projects, fix the names, and then add the projects again? (Once I've manually inspected file name and dates in each subdirectory?)
There may not be an easy way from within VS. But there is a way.
First, do a rebuild all on the solution. The output will show each file and the directory it is in. If the directory and files have a mismatch, then those are the ones that will need to be fixed.
Find a mismatch, and remove the project from the solution.
Go to the file explorer and rename the folder. In my case, there were often some files in the folder that were kruft as well, and I put an x in front of the name (I'll remove all of those at the end).
Then, back in VS, add the existing project, browsing to the now correct folder name.
Do a rebuild all again, which will make sure no mistakes were made, and also allow checking that all folder and file names now match.
Related
So this might be outright stupid question, but I found no answer looking on the internet or fiddling with different buttons.
Say you have a project with several physical folders which contain different source files. Now you've decided that you'll create a new folder and move parts of three old ones in there.
In order to do so, I had to do the following:
Go into my project folder via explorer and create a new folder
Manually move all the desired files into that folder
Return to code blocks and remove all the moved files from the project
Re-add all the removed files by selecting the whole new folder when adding existing files
Manually going through code and modifying all affected include directives to point to the proper path
It would be much simpler if you could right-click a folder, create a new nested folder and just drag-and-drop files to where you want them while code blocks would move them on disk and correct the includes for me.
It's the way that Eclipse does it for Java. Is there similar functionality for code blocks, maybe a plugin?
The project setting Debugging / Working Directory in Visual Studio 20015 will be saved by default in the *.user file wich I don't check in in to my repo because it's user specific. Still, I would like to have something other than $(ProjectDir) standing there when I do a clean checkout of my project. Is there an other place to store the Working Directory besides the *.user file?
Edit 1: The original idea is that I have a solution with multiple projects and all the binaries (dlls and exes) created end up in a folder called bin. If I want to debug it, I don't want to always edit the working directory again after a clean checkout.
Edit 2: In a post build step of every project within my solution, I copy the binaries in to the bin folder. If I start one of the executables from within VS, it starts them from the $(ProjectDir) folder, and of course not from the bin folder. This is why it does not find the dlls and why I want to set the working directory. I could change the output directory of my projects but then I get a lot of files ending up in the bin folder I don't want there. I will try it anyway; maybe I missed something. To be continued...
Edit 3: As expected, if I change the output directory to the bin folder, everything works fine except for some extra files that end up there and I don't want that (e.g. *.pbo, which would be okay, *.iobj, *.ipdb, etc.) Maybe that is the price I have to pay, but I don't like it.
So, the question remains: How can I have more control over which file ends up where after a build and still be able to run it from VS without changing the working dir?
The working directory should not have to be the directory that contains your DLLs. In fact, you definitely don't want that to be a requirement for running your application. Not only is it a hugely unexpected failure mode, but it could also be a potential security risk.
Put the required DLLs in the same directory as your application's executable. That's the first place that the loader will look. If necessary, use a post-build event in your library projects to copy them there.
Well since no body can help me I decided that I will change the output directory to the bin folder so VS will start my applications from the correct folder.
And how I can get rid of all the extra files that don't belong there I will find a way later.
There's a directory structure (the root folder and a bunch of subfolders with their subfolders in them etc.) and I'd like to keep these in our TFS, as a part of the solution, even if those are not source code files and don't belong to a project.
Optimally, those would be listed as "others" or "solution files". However, I can put them in a project if there's a suitable type of such.
When I tried to add these to the solution, the root directory's files get added but none of the subfolders nor the files in the subfolders. Is it possible to add a non-shallow directory structure to a solution somehow?
As the image depicts, there's a folder called Misc. In that folder, only the files from the root directory get added. How can I add the whole structure with its depth preserved? Or is there a more appropriate way to keep such files within a solution?
From How do I add an existing directory tree to a project in Visual Studio?
Add the folders to your folder directory
Show all files
Include the subdirectory in the solution
I am an inexperienced Mercurial user. I am using VS2010 with Mercurial. I had everything working nicely against a single repository, which contained a solution file and two projects nested within the 'parent' folder. Whenever I changed a file then the commit process would detect the change etc, etc.
Then I added a third project. I added this project in a new folder, where the new folder was a peer of the top-level folder containing the original solution file (with original 2 projects nested within). Although the third project has been added to the solution file, it is not being recognised by Mercurial as 'belonging' to the solution in terms of source control. Indeed, it is not showing as being under source control at all.
How do I add the third project to the same repository, even though it sits 'outside' the original folder which maps to the original Mercurial repository?
Thanks very much.
No, you cannot add anything that is not under the repository root. hg add will abort with X not under root message. Move your files into the repository, or move the repository so that all of your files are under the root (note that this will generate a lot of file moves, and you really shouldn't do that).
I found the best way to manage multiple folders in one repo by just creating a symlink (mklink in windows). I usually work in Visual Studio, so I typically have a code library and a website directory, but they are not in the same parent folder.
You can create a symlink on windows like so:
mklink /J "Target Path" "Source Path"
So I would have a structure like so:
project root
- Code Library
- Solution File
- Web Folder (symlink from locally-hosted website folder)
You should use a different repository for each project. This is because when you do a commit in hg, the commit is for the entire hierarchy, not just the directory (and below) that you are in. For more details have a look at the One last big conceptual difference section of http://hginit.com/00.html
what is copy items into destination group's folder (if needed)
is this a good option? If I dont choose it will it just make a reference to my files?
Also if I have two images with the same name like /images/home.gif, /public/home.gif
but they are in different groups how does the compile know which image to use? is this even possible?
I'll have a crack at this :-)
1 & 2 - Used when adding files to a project. If selected, the file you are adding is copied into the projects directory from wherever it originally was. Note it is copied. If not selected, the project can still use it, it just has a reference to the original source file. Which means that if something happens to the original file, the project will not longer have a copy it can use. Personally for files such as images I copy them into the project so they stay with the project. For other things such as external apis, I don't because I don't want multiple copies everywhere.
3 - If you have two images with the same name you won't be able to copy them in without renaming one. XCode may do this for you, I've never tried. I'd suggest renaming one so you control it's name.
4 - Don't get confused by groups. They are logical groupings of files within XCode and do not refer to the underlying file system. Having said that you can actually assign a directory to a group so if you really wanted to you can match the two. I tend to do it a little. In my projects I generally have a src and test directory. I setup two groups and assign them to refer to these directories. Then when I create a new source code file I can create it in the src or test group and it will be created in the sub-directory instead of the project root directory. Often below src and test I will use other groups, but they do not map to any sub directories. The result is that the root directory of the project is free of source code files and the source code also has source and test code separated.