Let's take this one by example. I'm developing on linux and using XamarinStudio for all of my .NET projects. I like it more than having VisualStudio running in the virtual machine. I have a solution that has several projects in it, that looks like this:
/Solution
/Solution/Project1 -> project number 1
/Solution/Project2 -> project number 2
/Solution/Project3 -> project number 3
/Solution/Output -> output folder for all projects
/Solution/Temp -> temporary files for all projects
I'm able to set the output directory for all projects, but I don't know how to set projects to generate temporary files to the Temp folder. Right now temporary files are generated into /Solution/ProjectX/obj/x86/Debug/ and /Solution/ProjectX/obj/x86/Debug/. How can I change it? I couldn't find the way to set it in the project/solution properties.
If you are using MSBuild to build your projects from within Xamarin Studio then you can use the IntermediateOutputPath element in the project file (.csproj) to override the default directory where obj files are stored.
<IntermediateOutputPath>..\Temp\ProjectX\obj\$(Configuration)\</IntermediateOutputPath>
You can change where obj files are saved by editing the project file (.csproj) in a text editor and adding the IntermediateOutputPath so it points to your temp directory. You will probably want to have different directories for each project.
I tried this with Xamarin Studio 5.7 with Mono 3.12 on the Mac and it seems to work. This should also work with Visual Studio.
Related
I've used dotnet cli to create a solution and subsequent projects inside.
As part of the exercise i am also trying to create folders within the projects to store different type of classes.
I use mkdir to create the folder, which works however when i open VS2019 the folders don't appear in the solution.
How can i create the folders and link them to the solution?
EXAMPLE of my cli code. (This is done on Win10 machine)
dotnet new sln -n TestService -o TestService
cd TestService
dotnet new webapi -n TestAPI
cd TestAPI
mkdir TempFolder
cd ..
dotnet sln TestService.sln add TestAPI\TestAPI.csproj
Open in VS2019, the TempFolder is not in the solution view, however does exist in Folder view.
Project folders
In modern .NET Core projects (using the .NET SDK), files are automatically added based on a global file pattern. For example, any .cs file anywhere within your project directory is by default automatically configured to be a part of your project that needs to be compiled. This pattern however only applies to files, not directories.
Directories are not an explicit part of a project by default. Instead, they are only there if they are “needed” for a path to a file. That’s why you won’t see folders within Visual Studio until there is a file that is part of the project.
If you are within your project folder and then add a folder there, you will not see the folder there. But as soon as you add a file to that folder (echo '' > TempFolder\Test.cs), it should automatically be picked up by Visual Studio:
You can also enable the “Show all files“ option in the solution explorer, to make folders that are not part of the project appear in the solution folder:
As you can see, the folder appears as a transparent item because it is not part of the project itself. You can then right click on the item and choose “Include In Project“ to make this folder an explicit part of the project. This action will add the following section to the project file:
<ItemGroup>
<Folder Include="TempFolder\" />
</ItemGroup>
This basically tells Visual Studio that the folder is part of the project even though it does not contain any files. As soon as you do add any file to the folder, Visual Studio will remove that configuration though since the folder is now again an implicit part of the project.
Solution folders
Visual Studio solutions don’t show the actual directories within your solution directory but rather a virtual directory as configured within the .sln file. Projects being located within subdirectories will not automatically be located within such a folder within the solution structure, and similarly non-project folders will also need to be added to the solution file first.
There is no mechanism to manage the solution folders with the dotnet sln command though. The only thing that you can do is add a project into a particular virtual folder within the solution:
dotnet sln add path/to/project.csproj --solution-folder VirtualFolder
This would add the project.csproj inside the VirtualFolder solution folder within the Visual Studio solution.
If you want to manage the solution folders otherwise, you should do that with Visual Studio.
I have many java files on one directory and I want to use it in my Intellij project. But I don't want to copy the java files to my project each time when I start a new project.
I know I can use reference in Visual Studio and Xcode.
I'm wondering whether I can do it in Intellij(14 CE)
Project Structure -> Modules -> Add Content Root -> (select directory containing external source files).
IntelliJ should detect the content as a Source Folder. If it doesn't detect it correctly, you can select it in the right-hand-side of Project Structure, and Mark as: (Sources).
I am using Wix 3.9 and when I run a continuous integration build in TFS I get an error
heat.exe: The directory could not be found because TFS is putting binaries in a different location to my local machine, so the project will build locally but not on TFS.
In my wixproj file I have a location set for the binaries which works locally
Dir=$(SolutionDir)\ProjectName\bin\$(Configuration).
Is there anything I can set this to which will find the binaries both on my local machine and TFS?
I am looking for something like the project reference variable $(var.MyProject.TargetDir), but this doesn't seem to work in wixproj files.
I worked around this issue by changing my project files to output the binaries to the same location as Team Foundation Build. That way both desktop and continuous integration builds can use the same reference to the common binaries directory.
If you are using Team Foundation Build 2012 or earlier your directory reference would be: Dir=$(SolutionDir)..\Binaries\$Configuration. The corresponding output path in a C# project would be ..\..\Binaries\Release or ..\..\Binaries\Debug (assuming the project folder is located in the root of the sources directory).
If you are using Team Foundation Build 2013, the same technique can be used, but the Binaries folder becomes bin. Your directory reference becomes: Dir=$(SolutionDir)..\bin\$Configuration. A similar change is required to the project output folders.
Team Foundation Build 2013 has additional options to control the output location, where you can put the output binaries in the same layout as your project structure. I've not used that personally but that might provide a solution.
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 new to WiX and am trying to get my install project to build certain files to a subdirectory of the build output path. For example, if my build output path is: bin\Debug, I would like certain files to be added to a subfolder here: bin\Debug\Images.
Is this possible please?
It looks like you are using a WiX project template with Visual Studio, MSBuild and/or SharpDevelop. If so, you have several options:
Use XCOPY in the Post Build Event.
flexible
somewhat easy to find in your project (on one of the project designer tabs)
not integrated well with the build system
Add the folder and files to your project folder, include them in your project and set the Copy to Output Directory on each file. Note: you can't set that property on a folder. The copying will preserve the folder structure but you have set the property on each file you want copied.
inflexible
very easy to find in your project (solution explorer and properties window)
Open the project file in a text editor and add MSBuild tasks such as Copy to the AfterBuild or other target. Note: To use VS to edit the project file, right click, select Unload Project, then right click and select Edit.
flexible
hard to find in your project (XML in the project file)
uses the build system
In the last case, I sometimes put a REM comment in the Post Build event to clue people into the fact that the project file has been customized.