Whenever I publish my web application I select "only files needed to run application". Upon publishing then it all works fine except for the bin/ folder contains a.svn folder. Is there a way to keep it from copying the .svn folder?
No I do not believe this is possible. The standard way of hiding a folder or file from the publisher is to prefix the folder name with a _ (yes that really is the case). IIRC this would break .svn and hence tarnish your enlistment.
I do want to ask why do you have a .svn folder inside bin\? This folder should only contain the binary outputs of the build process and other generated artifacts. Typically it's not the type of stuff you include in source control.
Related
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.
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.
I have moved binary files into the project under the bin folder to avoid publishing the same binary files twice since one of the binaries is huge; i.e. 15MB.
This was originally in a separate Includes folder. So the files were being copied twice to the publish folder.
Is the bin folder the correct placement for these or are there other steps I should take?
Edit:
Sorry if I gave a poor explanation (and original title). I've changed the title; this was "Where should static libraries (3rd party DLLs) be kept in Visual Studio?", and is now, "How can I avoid publishing the library folder in a Web Publish?"
As mentioned, I originally had a separate folder named Includes. When I did a Web Publish, each of the DLLs are published twice; one into the bin folder, the other into the Includes folder. In this case, I am publishing at least an extra 15MB of unnecessary file space. Normally, not a big deal but if I am on a very slow connection, I'll need to wait longer to deploy the project to its environment.
I moved the DLLs back into a separate folder but the folder is still published along with the bin output folder. I did this to see if the placement of these files would set their properties differently.
I have tried various settings for Build Action and other property settings for these libraries without success.
Is there no way around publishing the DLLs twice?
If these files are part of the overall source of the system (not necessarily as source code, but as source-control-tracked artifacts nonetheless), then you probably don't want to keep them in the output folder for the build. The output folder should be transient and shouldn't be tracked in source control.
Keep 3rd party libraries in a library folder. The folder structure in source control might look something like this:
/
--/lib
--/Project1
----/SomeSubFolder
--/Project2
----/Images
----/Styles
and so on.
Each Project would have its own bin folder when it gets compiled, which itself may contain other folders for types of compilation (Release, Debug, etc.). But you don't want those build artifacts tracked in source control or in any way interfering with what's in source control.
The projects would reference their library dependencies, and at build time those dependencies would be copied to the output folder to be used by the application runtime.
Whenever I am adding some files to my project by dragging and dropping in Xcode, a popup message is shown "Copy items into destination's group folder (if needed)".
I noticed that when we are using most of the third party library's we DON'T tick the checkbox and instead specify the library path in "Header Search Path/Library search Path". But for smaller resource files like images, we tick the checkbox.
Which specific scenarios do I have to tick and what difference will it make?
It all depends on how you want to organize you project. It's far more common to store 3rd party frameworks somewhere on your machine that is independent of any project that may use that framework, thus allowing multiple projects to reference the same shared framework project from a standard directory. In that case, you don't want the 3rd party framework copied into your own project, and so you don't check that box.
Images and other resource files are typically owned on a project-by-project basis, so it makes the most sense to store those in the directory of the project itself. To pull that off, you check that box to make sure a copy is made in the project's directory if one doesn't already exist.
Neither of those rules are absolute, you could copy an entire framework into your project's directory if you want, and you could reference media assets from some standard location. It's all up to you to implement good project organization.
Typically, your project is saved to a project folder. If you drag stuff from outside the folder into your project without copying, only references to the added files are stored. You will have to be careful not to delete them, or your project will break.
Also, if you are using version control, such as the built-in git, files not in the main folder will not get added to your version tree.
I got into the habit of copying everything I need into the main folder and then drag-add without copying. This is working well for me and has so far avoided any errors.
If I use the publish feature in VS2008 (I think it's called ClickOnce install), and then install the published application in another computer, where are the files copied?
In other words: If I need an auxiliary file (a .txt file) in the same path of the assembly, where do I have to create it?
Thank you.
You should have specified the location when you published the application. Just note down that folder.
If you run the wizard again for the same project it should have remembered the location and the folder will be pre-filled on the form.
I've used this and I specified a location on my hard drive for the Publishing Folder Location. This folder contains the following files:
publish.htm
setup.exe
[application].application
It also contains a folder called Application Files which contains the files needed to build the installation - the exe, the manifest, other dlls and external resources.
I then copy the three files and the folder to the web location specified by the Installation Folder URL.
If you're talking about where the files get installed to then they're in:
C:\Documents and Settings\[user]\Local Settings\Apps\2.0\H165QZM1.QBE\0OAEZTRX.Y3N\[some truncated version of the exe name followed by a GUID]
Which isn't the most obvious place. I should also point out that the folders H165QZM1.QBE and 0OAEZTRX.Y3N will probably be different on different machines, but the only other folder under C:\Documents and Settings\[user]\Local Settings\Apps\2.0 is called Data so they should be easy to spot.
Is the application available offline or online only? My experience is online only and in that case I believe it installs into a temp directory. Can you include your auxiliary file as part of the application files? This may help as well it talks about including data files which can be of any type.
http://msdn.microsoft.com/en-us/library/d8saf4wy.aspx
http://msdn.microsoft.com/en-us/library/6fehc36e.aspx