I am using cmake to generate my solution files and I'm doing that out-of-source. So I have a myproject folder and a myproject_build folder. When I save my ReSharper settings in team solution, it creates a dotsettings file in the myproject_build folder.
C:\
myproject
.hg
CMakeLists.txt
myproject_build
myproject.sln
myproject.DotSettings
How can I make sure that saving these settings goes into the source folder and be sure that all team members have the same settings?
I guess I would place a common dotsettings file into myproject, the file that you and your team will modify in the future. During generation of the solution into myproject_build you should generate a myproject.sln.dotsettings file as well, that need to hold a reference onto the file from myproject. You can include any other dotsettings file by going to ReSharper | Manage Settings and then right-click any layer (team-shared in your case) and add the particular file.
Related
I have a Visual C++ project that I have developed on one computer and have committed it to a repository and pulled it onto another computer. When I open the solution and attempt to build it on the other computer, the solution won't build and upon checking (Properties -> C/C++ -> General -> Additional Include Directories) is empty along with the Linker Additional Dependencies. Is there something I'm missing in the repository? The repo has the solution and all of the newly written source and header files as well as the following file types in the project folder:
.vcxproj
.vcxproj.filters
The filters file seems to have all the directories in it but for some reason, the solution isn't recognizing it. Is there a way to correct this or do I have to go down the rabbit hole again and manually include the directories all over again?
I have created a Class library file in c# named as AssemblySettings. Then i added Configuration files. When i build the project, in bin folder config files and AssemblySettings.dll.config file was created.Then i want to add assembly settings in AssemblySettings.dll.config. But in solution explorer .dll.config file was not created. Kindly help me.
This file appears as app.config in Solution Explorer. The build process changes the name to NameOfAssembly.dll.config and puts it in the build folder.
I have added a new nuget package to my solution.
In the "Team View -> Pending Changes -> Detected Changes" there are some of the files, but /lib folder is ignored. As a result CI build breaks.
Question: where is it specified in TFS (or Visual Studio?) to exclude /Lib folder (or files inside /Lib folder)?
Given you're using TFS2012 I assume you're using a local workspace. For local workspaces files are ignored using the .tfignore file. Check if you have that file present and if there is an exclusion for the /lib folder in it.
Also note that by default certain files are ignored, such as the .dll files that would be in the /lib folder of the nuget package. If a folder has no files to include it will not be shown in pending changes. You will have to add it manually via source control explorer.
Here's the reference for the .tfignore file if you want to see how it works.
You can quickly determine the location of your .tfignore file by choosing to ignore something in your detected changes. This will cause the .tfignore file to appear in your "Included Changes" with the new ignore setting (it will be created if it didn't already exist). From here you can double click the file to open it up for editing.
Using a InstallScript C# .Net Wizard to connect to a WinForms solution where I used the dependency scanner to identify project outputs.
The install package is copying the un-merged app.config file to the target directory instead of the solutions merged MyApp.exe.config file. This results in a executable that does not properly pickup configuration file settings not only because the file isn't named correctly but it also does not merge in target environment settings (ie. release, debug, etc.).
How do you have the Installer copy the merged MyApp.exe.config file to the Install Directory?
Try this, I believe this should work.
Select the config file, and in the Copy to Output Directory under File.Properties, choose Copy always or Copy if newer. You can choose any file you like with this method. Basically this file will be placed to a directory where the binaries are built. This is still a better method than configuring/fixing from InstallShield, I think. I will like to hear from you, if you disagree.
Another thing, a config file is used and determined at run-time by code. That’s probably the reason why InstallShield does not know the file dependency on it. And it is out of scope for that tool.
Have fun and let me know what happens.
Tommy Kwee
I am using SlowCheetah to do my app.config transforms and here is what we're doing to get installshield to work. For postbuild step, copy all files needed by installshield to a separate Install folder (i.e. copy "$(ProjectDir)$(OutDir)." "$(ProjectDir)bin\Install"). Point installshield to that folder to build it's output
I'm also using SlowCheetah for my config transforms, but the real answer to this question is that the InstallShield project pays attention to the selected Solution Configuration. If you select the Release configuration before building the InstallShield project, the Release output will be used in the install package.
I have been working with setting up TeamCity, and I have almost everything working with the exception of being able to compile VS2005 solutions that have referenced assemblies that are outside of the solution path. I have our SVN repository structured as follows
Root
Libraries
Project 1
Trunk
Project 2
Trunk
Project 1 and Project 2 reference third party assemblies located in the Libraries. This works just fine from within the VS2005 IDE and when calling MSBuild on the solution files since the HintPath for all of the references look like this:
..\..\..\Libraries\ThirdParty.dll
The problem I have encountered is that when TeamCity dies the checkout from SVN for Project 1 or Project 2, it places everything into internal directories that don't match the structure of the relative path given by the HintPath.
How do I go about clearing this up, either through a TeamCity configuration or configuring my solutions/directory structure differently? Either one will work for my needs.
Thanks!
If you create a separate VCS root for Libraries, you can use checkout rules to control where the files are placed in the directory structure so that it matches the structure on your local machine.
We set up a network directory with all our third party dlls. Then we mapped the directory to a drive.
That way the dlls weren't a part of our solutions and all projects just call z:\3rdParty\example.dll to get the assemblies.
Someone else on my team actually set up our teamcity, so I could be completely mistaken about how the problem was actually fixed or if we even had that problem initially :)
What i have done is to set the VCS ROOT of the project to the top level directory ("Root" as per your project structure). And detached the default project vcs root created by teamcity. After this you can create a custom build step by specifying your solution here "Solution file path: *" in build type "Visual Studio (sln)". Now it properly handles library references.
There is a drawback here in that, since the vcs root is at the top level, even unrelated check ins could cause your project to build and that may not be suitable for time consuming builds. Don't have a workaround for that yet.