Dinking around with stylecop settings files is getting annoying and messing with my repo structure. The repo is like this:
+ Trunk
+ src
- ProjectA
- ProjectB
- ...
+ lib
+ Icons
- ...
+ tools
+ NUnit
+ PartCover
- Settings.StyleCop
- ...
I would like all projects/solutions to use the settings file from trunk/tools and no others (preferable I'd like all settings file for only projects in this trunk to use that settings file, but system wide is acceptable.
I must be the only person who finds the way stylecop deals with settings files and merging settings files to be really annoying, or I just don't understand it properly.
You can create a parent settings file, which applies to all projects in subfolders of the folder where the settings file is located:
Sharing StyleCop Settings Across Projects
BUT: that means you can't put the settings file into the trunk/tools folder.
You have to put it directly into the trunk folder instead.
But in my opinion, that's no problem. I did this in my own project as well:
The StyleCop assemblies and the target file are in a subfolder named \Libs\StyleCop, only the settings file itself is in the root folder. I can live with that.
If you really don't want to put the settings file in the Trunk folder, then you do have one other option: Replace the settings file in the StyleCop install directory.
Definitely 'an option of last resort', it makes the project validate differently on another computer that hasn't replaced the default StyleCop settings file.
I wouldn't recommend going down this path unless absolutely necessary.
The best way to make all projects use the same settings is by having the settings file in the topmost directory shared by all projects, that's all there is to it.
Updated
See this guide (under, Analyzing All Projects) if you are using StyleCop.Analyzers nuget package.
If you are using StyleCop Installer (this is the old version of SyleCop), this is how it can be done:
I have several projects in my solution and I am using my Web project's StyleCop setting as the main (global) setting :
To do this, right click on any other project => StyleCop Settings
Choose: Merge with the following Settings file and choose the your main project's settings.StyleCop (in my case the Web project's setting):
That's it, now your main projects settings would be used for the other (child) project.
You can confirm this by opening your child project's StyleCop setting (note that it's hidden in VS):
And you can see that is referencing your global setting. You can repeat these step for all other required projects.
Related
(I no longer want an answer. OML, my English has surely improved...)
How to use assemblies in a VS solution under source control and keep assemblies updated?
(Source control is provided by the codeplex and VS default options for it.)
I mean,I have a project named HyperAero.
I have another project named TestAnimation.
TestAnimation is under source control and needs hyperaero.
When I check in,HyperAero.DLL will not be saved in server.Of course,I can add hyperaero.dll to my solution as a file but I want it to stay updated with my changes in HyperAero project automatically.
What should i do?
Answer (Got it myself):
command:
robocopy "E:\Documents\My VS\Fix soft HyperAero Form\Fix soft HyperAero\bin\Release" "E:\Documents\My VS\Fix soft Animation Maker\Test of Animation Maker\DLLs" "*.DLL"
set rce=%errorlevel%
if not %rce%==1 exit %rce% else exit 0
Similar Question (Remember that i want my assemblies to stay updated):
When using custom assemblies in a visual studio project. How does one check in those assemblies in source control with the project so that anyone can download the project and build right away.
There are two way to approach this:
1/ Don't put the assembly dependencies in source control and always include in your solution their Visual Studio project instead. In your case you'd have a solution with the Hyperaero project and TestAnimation project with a project dependency to the Hyperaero project.
This way you don't have to put the generated DLL in source control and keep it updated each time you change something in the code.
2/ If you really want to dissociate both projects, then I'll recommend you to use Nuget and build a Nuget package for the Hyperaero project and then reference the Nuget Package in you TestAnimation project. This approach is the cleanest one, but it may be overkill and at last it's not something you'll setup quickly (compared to 1/).
Put both projects in the same solution and add a project reference.
Use your source control's UI / command-line to add the DLL files.
What source control software do you use?
If you are using subversion:
ankhsvn (Visual Studio plugin) can handle multipe repositories in one solution.
I have the following structure.
- App1\
App1.sln
App1Forms\
App1Forms.csprj
- App2\
App2Dll\
App2Dll.csprj
Now If I open App1.sln and add App2Dll, which is outside the folder structure, as a project, the project gets linked as a relative path. I am fine, if I check out both sources to the same parent directory.
Ankh is aware of that and If I hit update both projects gets updated.
If I want to commit changes I am only allowed to commit to one repository at a time, but again, ankh informs me about that.
Another way is to use svn-externals http://svnbook.red-bean.com/en/1.0/ch07s03.html
which will transparently include one repository inside another.
I am wondering if there is a way to set the deployment setting under Local.TestSettings in a Visual Studio 2010 Test to a relative path. Right now we have to copy over a couple of DLL's in order to use our tests correctly. We have this path hard set on a machine, but this gets messed up if you accidentally commit that file and then someone updates.
You can use test setting to add one deployment item. And continually use notepad to edit the *.testsettings file. Then, manually add "outputDirectory" attribute to the deployment item.
For example, there is one folder named "Config" in "myProj" which contains your online codes. And you want to copy all configuration files under the folder - "Config" to your test project - "Test.myProj" and make them also be placed under "Config" under "Test.myProj"
So you need to manually change the *.testsettings and add the following item in the file.
<Deployment>
<DeploymentItem filename="myProj\Config\"
outputDirectory="Test.myProj\Config\" />
</Deployment>
P.S. VS2010 did not allow to input value to "outputDirectory". So u have to use notepad or text editor to update it.
What is the source for these DLL's? How are they being used, as reference DLL's? If they are third party DLL's the tactic we usually do is place them into a "Reference DLL's" folder and add them as deployment items. When VS goes to execute the test it will copy them to the OUT folder along with the test DLL. Now that they're both in the same folder your tests should have no problem finding the needed reference DLL's.
If these DLL's are of your own creation (or your group/organization) I would add the project to the solution then add the reference as a Project reference. VS will automatically detect the dependency and compile the additional projects and copy the built reference DLL's to the out folder.
I created a Netbeans CPP Project in my Mac and uploaded it into git. The project has collaborators who use Windows.
When I pushed my project into github , I pushed the makefile information too (the whole project). Now the collaborators are getting build errors because the reference contains my Mac filepaths.
The Windows machine have cygwin installed.
How do I resolve it ?
How I do make it platform independent ?
What should I (and collaborators ) do to not affect the other workers ?
ANSWER : Netbeans has an option (in the project properties under c++), to have the file path as absolute or relative. So I all had to do was, set the relative option and push the changes . The project started working for everyone ! VOILA !!!!!!!!
Netbeans has an option (in the project properties under c++), to have the file path as absolute or relative. So I all had to do was, set the relative option and push the changes . The project started working for everyone ! VOILA !!!!!!!!
I've found that the project files generated by NetBeans for C++ are rather unweildy and aren't very maintainable by humans. And while they do tend to reference paths relatively from the root of the project (facilititating copying the project to different directories), there's just too many project files to maintain. And you're sol if they don't work.
I don't know if NetBeans allows you to specify environment variables for paths in the project settings dialogs. The macro/variable stuff is largely undocumented as far as I can tell. But if you know how to do that, then define all your file path dependencies by an environment variable instead of a hardcoded path in the project settings window. Remote developers need only redefine the environment vars on their machine.
But I think a better solution is to not use the NetBeans auto-generated Makefile from Project Settings. Instead, declare your own Makefile and create a NetBeans project type from "an existing Makefile". I've found that works really well.
Then you can have a line at the top of you Makefile as follows:
include common.inc
Where "common.inc" includes all the hardcoded library paths that are machine dependent. Here's an example of mine:
BOOST_INCLUDE := -I/home/jselbie/lib/boost_1_46_1
OPENSSL_INCLUDE := -I/home/jselbie/lib/openssl
And then my Makefile only references these directories by variable name. And so when I move the project around different machines with different configs, I just need to update common.inc.
And then if anyone else wants to use NetBeans to compile my project, they just need to create a NetBeans project from "an existing Makefile" option.
The option for relative file paths is actually NOT in the project properties! Instead, it's in the top menu bar.. choose "Tools" then "options" then click the "C/C++" tab, and the second box down is "File path mode" select "always relative"
For a long time looking for a way to manage references, I haven't found any ideal way.
The main problems are:
1-) Should I include all projects that I use in same Solution and reference the Project? Or reference just the dll file?
2-) If I should reference dll file, the best way is to create a ReferencedAssemblies inside each project or a main folder at svn root?
3-) Its ok paste and reference dll´s inside bin folder of my project?
4-) Its ok add and commit dll´s inside bin folder of my project? This way when a new devoloper checkout the project, it will compile perfect, but isn´t default behavior of visual studio, all source controls ignore bin and obj by default, just adding .refresh files(for web-site project)
Someone can help me?
1) If you include projects in your solution that are already checked in somewhere else, you can change the SVN binding for that project at the solution level in Visual Studio. (File > Source Control > Change Source Control). You would change it to point to wherever it's located in your SVN repo.
2) If you have a lot of developers on different machines all wanting to use the same libraries, it's probably easier to have a common place for all your third-party libraries/assemblies. There's no point in having them copied all over the place in your SVN repository.
3) No, it's not usually ok to do this. I would avoid it (unless somebody has a valid reason for it).
4) Never commit your bin folders. The default behavior is such for a reason. The .refresh files are byproducts of the old Web Site projects and they are fine.
1) In the typical scenario yes, you should reference all projects that you own. But you should make a decision according to frequency of changes made to referenced projects. For example if you have an open source library it is better to include it as an assembly, cos you probably will not change this code frequently.
2) Typical approach is to create separate single directory at SVN root and place assemblies there in different sub-folders according to assemblies type. Here is how my current folder looks like:
3) No, it is better to reference assemblies from some other from bin folder. All referenced assemblies will be copied to the bin while building process. Also note that the purpose of *.refresh files in the bin folder is to prevent you from having to copy new versions yourself.
4) No, you should never commit your bin folder cos you can rely on *.refresh files for WebSites and just forget about this problem for other project types.
1) I'd argue it depends upon your particular situation, especially since Visual Studio is pretty flexible on what projects are included in solutions. (It's not tied to a directory structure.)
We have a couple applications that have one solution with a number of projects contained within (for each 'piece').
2, 3, 4) For referencing and including files within a project, why not just use the functionality built into Visual Studio? Adding references in this way adds the items to your csproj (vbproj) files.
(Based on my research, if you're not referencing a project that's part of the solution, put the DLLs in a directory everyone on the team can access and use that when adding the reference. In the project file it ends up looking like this:
<Reference Include="Elmah">
<HintPath>\\pathInformation\shared assemblies\ELMAH 1.1 32-bit\Elmah.dll</HintPath>
</Reference>
)
This also means that you don't have to commit DLLs; if anything changes the project file will be updated accordingly.
(I'll admit, I'm unsure about that last point. I've seen a lot of people check in external libraries, like ELMAH. I generally follow those who tell you to ignore the bin directory entirely.)
I have a Web Setup project in VS. I'll be switching to WiX, but that's in the future and currently I need to solve the following issue.
I need to exclude some common dlls from the project. So I build the project, VS updates the list of Detected Dependencies. I exclude them and the setup builds. I check the file list with Orca and the files are not included in the installer.
But when I clean my output directory, reload the solution and do the build, some of the dependencies do not show as excluded! And so they end up in the MSI. (This is what is happening on the build machine).
I think that the problem might be with the fact that these are second-level dependencies:
my app -> NHibernate.dll -> Antlr3.Runtime.dll
(Antlr dll ends up in the MSI).
Is this a bug or am I missing something?
I found this page on msdn that has a work-around for the Exclude flag being reset to False:
Previously excluded files are included again when the solution is re-opened
When you exclude a file from a Setup project, you may see that the file is included again after you close and re-open the solution. This may occur if there are two copies of the same DLL file from two different source locations.
To work around this error, change the Copy Local property on one of the files:
In Solution Explorer, click on the DLL reference that you want to remove.
On the View menu, click Properties Window.
Change the Copy Local property to False.