I have two versions of a project. One for Silverlight and one for .NET. The SL project has the vast majority of the code base in it. I want to globally add all files from the SL project into the .NET version as linked files. I've managed to do so successfully like this in the csproj file for the .NET version:
<Compile Include="..\MyProj.Common.SL\**\*.cs" Exclude="..\MyProj.Common.SL\Properties\**">
Unfortunately, this adds all the files right to the root of my project... so I end up with a long unreadable list of linked files in the .NET project. I really really really don't want to have to maintain an entire duplicate directory structure by hand and deal with directory name changes and file name changes and whatnot.
So, is there any way to have Visual Studio preserve the directory structure when adding linked files in the wildcard manner above? Or is there at least a way of making it group all the linked files together under a directory in the .NET project like MyProj.Common.SL.Links?
The very closest I've come is to set the <Visible>false</Visible> under the <Compile> tag, which effectively removes the long unreadable list of 300+ files....but unfortunately this screws up Resharper, which no longer sees those files as valid and it goes crazy on all the projects that reference the .NET project. If I could figure out a way of making Resharper not get all messed up, that would be an acceptable solution too...
Any suggestions?
Thanks.
I think I found a way of getting this to work:
<Compile Include="..\MyProj.Common.SL\**\*.cs" Exclude="..\MyProj.Common.SL\Properties\**">
<Link>MyProj.Common.SL.LinkedFiles\MyProj.Common.SL.LinkedFiles</Link>
</Compile>
It will create a MyProj.Common.SL.LinkedFiles folder and group all the linked files under that folder.
I think I would do this:
Copy the existing project's <Compile> items, which presumably have e.g. Include="foo.cs" and Include="Folder\bar.cs"
Paste them into the new project
Search and replace <Compile Include="(.*?)" /> with <Compile Include="..\Other\$1" ><Link>$1</Link></Compile>
I don't know if I got the regular expression search and replace syntax exactly right, but the point is, you already have a good project, you should be able to cut, paste, regex-replace it to get the same set of files, only referenced from a different folder, and with the same directory structure.
You'll still have two .csproj's to maintain at this point, but this is also easily fixed. Now take this new list of compile items, and put it in a file named e.g. "Common.csproj" that just contains the property group with those compile items, and then have both projects <Import Include="..\Common.csproj" /> and not include any Compile items of their own.
Basically, a little manual labor to refactor the .csproj file for sharing once, and then I think you'll be set. I am not sure if this is the 'easiest' way to unblock you, but I think this sounds approximately like what you may want for an 'ideal' structure.
Related
I apologize if this is trivial, but I'm not a regular VS user and my Google-Fu is turning up nothing obvious or simple.
I have inherited responsibility for a large (500k+ LOC, a dozen solutions, hundreds of projects) repository that's been forked a number of times in the past. The solution/project structure is... spaghetti-esque, in that the filesystem folder structure and the solution/project structure are only weakly correlated, and many projects import/reference other projects outside the filesystem folder hierarchy of their containing solution, and that are not even part of the containing solution.
For example:
c:\SolutionA\SolutionA.sln contains c:\SolutionA\ProjectB.csproj and c:\SolutionA\ProjectC.csproj. But C:\solution\ProjectC.csproj contains a <Import Project="..\SomeOtherRandomSolutionDir\ProjectD.csproj" /> reference.
I know there are a lot of projects/files/resources in this repo that are not used by any of the solutions I'm actually building and I don't need them, but the tentacular nature of the project imports/references makes it hard to determine what's actually necessary for the builds and what's superfluous.
So: is there any relatively simple way to run a solution build in Visual Studio (or MSBuild) and obtain a list of every single file used by the build process? I've tried creating a diagnostic-level build log and grepping[1] it for the repo base path; will that get me what I want? (Narrator: it won't)
EDIT: Assume that all file operations are done entirely by default Visual Studio solution project handling and there's no custom targets or shelling out to copy or move files, in the way Perry Qian describes below
[1] Well, Get-Content | Select-String-ing it, but that's clunkier to say
is there any relatively simple way to run a solution build in Visual
Studio (or MSBuild) and obtain a list of every single file used by the
build process? I've tried creating a diagnostic-level build log and
grepping[1] it for the repo base path; will that get me what I want?
Sorry but I'm afraid this is not supported scenario. You cannot obtain a list of every single files that are used in a project or a solution during build process.
Let me explain it more detailed:
Usually the files which are in the solution explorer are all useful in the project. Since your solution is too large and logically complex, we do not recommend deleting any of the files, and I think they all work.
We can obtain a list of files which are parts of the input items of the projects by MSBuild(usually in <Itemgroup> node of the xxx.csproj file).This is the only way I can think of to get a set of project files through MSBuild. We can add this target into xxx.csproj to list all of them like this:
<Target Name="ShowSingleProjectItemList" AfterTargets="Build">
<Message Importance="high" Text="None file:#(None)---Compile files:#(Compile)---Content files:#(Content)---Embedded Resource files:#(EmbeddedResource)---CodeAnalysisDictionary files:#(CodeAnalysisDictionary)---ApplicationDefinition files:#(ApplicationDefinition)---Page files:#(Page)---Resource files:#(Resource)---SplashScreen files:#(SplashScreen)---DesignData files: #(DesignData) Reference dlls :#(Reference)">
</Target>
Note that this method can only be used for each project and not for the entire solution so if you want to use, add it into every xxx.csproj file.
But for other files which are not as the input items of the projects and added or referenced in the projects by some CMD commands or powershell scripts, build events(Right-click on Project-->Properties-->Build Events)(You can refer to this) and any other custom target in the xxx.csproj,we cannot list all of them by a function.
For example, if you use powershell to do some copy operation like coping some dlls from the path outside of your solution into projects,they can't stay in the project as an item of the project. So we cannot obtain them by MSBuild.
For this situation, we can only manually view all of them that are imported into the projects in whatever way in the diagnostic-level build log.
Conclusion
As input items of the projects, we can get the required files for each project by MSBuild, but for some other operations(powershell,build events,etc) to add files from other path outside into the current project,we cannot retrieve all of their information by a method. You can only look it up one by one by diagnostible-level build log.
Besides,we don't know the structure and logic of the entire solution, so we can't guarantee that every file is an item element, so for now you have to look at it manually.
Update 1
To avoid adding every target into your xxx.csproj(since you have a lot of projects under a solution), you can try to use Directory.Build.props. You just write the custom target into this file and then put the file under your solution. After that, when you build the solution, the build will execute into every project so that you just have to write it once.
Solution
1) create a file namedDirectory.Build.props under the solution
2) write these info into the file
<Target Name="ShowSingleProjectItemList" AfterTargets="Build">
<Message Importance="high" Text="None file:#(None)---Compile files:#(Compile)---Content files:#(Content)---Embedded Resource files:#(EmbeddedResource)---CodeAnalysisDictionary files:#(CodeAnalysisDictionary)---ApplicationDefinition files:#(ApplicationDefinition)---Page files:#(Page)---Resource files:#(Resource)---SplashScreen files:#(SplashScreen)---DesignData files: #(DesignData) Reference dlls :#(Reference)">
</Target>
3) build your solution and you will find the files in the build output window.
We have a very large number of solutions spread across a wide number of repositories which do not always share a directory hierarchy in a way that makes it easy for us to update an .editorconfig such that it applies to all projects/solutions in the organization. We currently apply all of our code analysis configuration via an internal NuGet package and I was hoping we could include our organization-wide .editorconfig settings in this way as well?
I tried a quick experiment adding the following to a project to see if linked files would be honored (since we could simply add this to a props file we already have in the NuGet package), but it does not appear to be honored currently.
<ItemGroup>
<None Include="C:\SomeAlternatePath\ECTest\.editorconfig" Link=".editorconfig" />
</ItemGroup>
Is there some other MSBuild property or mechanism we could use to better facilitate this without literally writing a duplicate file to every solution/project/repo?
Is there some other MSBuild property or mechanism we could use to
better facilitate this without literally writing a duplicate file to
every solution/project/repo?
I'm afraid the answer is negative. Cause the .editorconfig file have nothing to do with msbuild or xx.csproj. Only file hierarchy can affect the behavior how the config file works. More details please check this document.
Some tests:
When I right-click project=>add .editorconfig to add this file in current project, there's one line added to the xx.csproj: <None Include=".editorconfig"/>.
If we set the indent_size = 32, it works for current project. Now we can right-click that file=>Exclude from Project to remove that file from current project system. (This action will remove the <None Include=".editorconfig"/> in xx.csproj, but the file is still in the same folder where xx.csproj exists)
Now reload the project, the settings(indent_size=32) still works. So it's obvious if we place this file in project directory, then it will take effect, no matter if we have definitions about it in project file(xx.csproj).
Suggestions:
According to your description, all your projects use the same .editorconfig file. Since this file's working scope is affected by file hierarchy, you can reduce some meaningless work by:
1.Place that file in Solution folder, it will work for all projects under that solution folder
2.Place that file in repos(C:\Users\xxx\source\repos) folder, it will work for all solutions and projects under this folder.
3.So if most of your solutions are under path C:\somepath, place that file here, all projects under that path will benefit from that. And about precedence in file hierarchy please see this one.
Hope all above makes some help :)
I have read this post thoroughly: How does Visual Studio's source control integration work with Perforce? and found it very informative. However, I have a specific issue that is blocking my use of Perforce in VS.
For the most part, I have no complaints about the plug-in (I'm still using the P4VSCC plug-in because the new plug-in requires conversion by the entire team which can't happen at this time). Once I understood the idiosyncracies, I've had only one problem working with the plug-in.
Our solutions contains many projects that are built into a single deployment package. As such, each assembly is versioned the same. To accomodate this, and other common aspects, we have defined a common "SharedVersionInfo.cs" file which contains the AssemblyVersion and AssemblyFileVersion attributes typically found in the AssemblyInfo.cs file. This file is stored in an Assets folder beneath the solution folder and added to each project's Properties folder as a linked file. This works great from a version management perspective as we only have to change the version in one place and all assemblies are updated. However, Perforce has a problem with this when a new developer first opens the solution or when a new project is added. The only remedy we have currently is to remove all of the linked files (there are 3 per project in this solution), bind the project to source control, then re-add the linked files.
This isn't such a big deal when we add a new project but the solution contains 80 projects (and counting), so this isn't a viable remedy for a new developer!
My understanding is that the problem has to do with where VS thinks the binding root for each project is. After some research, I was led to find where the MSSCCPRJ.SCC files are for the projects. I found there are numerous SCC files scattered throughout the solution structure. So...
First question: Why are there multiple MSSCCPRJ.SCC files in my solution structure?
We also have several shared/common projects that we use in our solutions. This leads to the following folder structure:
/Source
/CommonTools
/ProjectA
ProjectA.csproj
/ProjectB
ProjectB.csproj
/MySolution
/Assets
SharedVersionInfo.cs
/Project1
Project1.csproj
/Project2
Project2.csproj
:
/ProjectZ
ProjectZ.csproj
MySolution.sln
Where both ProjectA and ProjectB are part of MySolution.sln
Second Question: How can I setup the bindings so the /Source folder is considered the root? This would ensure that all projects included in the solution are under the same binding root. Perforce considers this folder to be the root, how do I get VS and the plug-in to do the same?
Since no one else has offered up a solution, I thought I'd follow-up with my own findings for anyone else that comes across the thread.
First, I still have no idea why Visual Studio creates multiple MSSCCPRJ.SCC files but these are the key to establishing the "binding root" for a solution. It is critical that this file exist at the highest level necessary so that ALL of the projects in the solution are in sub-folders relative to the location of this file. In my example above, the MSSCCPRJ.SCC needed to be located in the /Source folder. Having it in the /MySolution folder caused the original problem when adding projects from /CommonTools into the solution.
That said, resolving the issue was no easy task. I had to manually edit the .sln and all of the .csproj files in Notepad. What I found was that some of the .csproj files had the following elements identifying the source control settings:
<SccProjectName>SAK</SccProjectName>
<SccLocalPath>SAK</SccLocalPath>
<SccAuxPath>SAK</SccAuxPath>
<SccProvider>SAK</SccProvider>
I don't know what SAK stands for, but my understanding is this tells Visual Studio to use the binding information contained in the .sln file.
I had to change these to:
<SccProjectName>Perforce Project</SccProjectName>
<SccLocalPath>..\..</SccLocalPath>
<SccAuxPath />
<SccProvider>MSSCCI:Perforce SCM</SccProvider>
where the SccLocalPath value is the relative path from the .csproj file to the MSSCCPRJ.SCC file.
I also had to change the SccLocalPathX and SccProjectFilePathRelativizedFromConnectionX statements for each project in the .sln file. The SccLocalPathX value should be the relative path from the .sln file to the MSSCCPRJ.SCC file - a dot (.) if in the same folder. SccProjectFilePathRelativizedFromConnectionX should be the relative path from the binding root to the .csproj file.
I wish I could say that having that in place, I never had to repeat these steps. Unfortunately, I still have to go in and make corrections every time I added a new project to the solution. Visual Studio still wants to use SAK for the elements in the .csproj file and sometimes the values in the .sln file aren't quite right.
But, at least I know what to look for and what needs to be done to achieve my goals. If anyone else has a better solution or a way to configure VS and/or Perforce so these settings are created correctly up-front, I'll gladly give credit.
Hope that helps...
I have some content files that I would like to share between a number of projects in Visual Studio.
I have put these files in their own project, set the build action to "Content", and the copy to output directory to "Copy if newer". I would like all these files to be copied to the bin/debug directory of the projects that reference them.
I can get it to work by including a reference to the "contents" project in each of the projects that need the files, but that requires that a minimal assembly be generated (3K). I assume there is a way, using MSBuild, to make this all work without creating the empty assembly?
Thanks to everone who took the time to make a suggestion about how to solve this problem.
It turns out that if I want my compiled content files to be treated like content files (in that they get copied to the output directory of any other project that references my project), I need to create a target which runs before GetCopyToOutputDirectoryItems, and add the full path of the compiled content files to the AllItemsFullPathWithTargetPath ItemGroup. MSBuild calls GetCopyToOutputDirectoryItems for projects on which the current project depends, and uses the resulting file list to determine the files that are copied along with the assembly.dll. Here is the XML from my .csproj, just in case someone else has a similar problem.
I have a custom task called "ZipDictionary", and I accumulate all the files that I am going to compile in an ItemGroup called DictionaryCompile. My target, "FixGetCopyToOutputDirectoryItems" is executed before "GetCopyToOutputDirectoryItems". I don't do the actual compilation there, since this target can be called multiple times by referencing projects, and it would hurt performance. The target does some transforms to get the post-compilation file names, and then returns the full paths to all the files, since relative paths will not work when copy is called from the referencing project.
<ItemGroup>
<DictionaryCompile Include="Dictionaries\it-IT.dic">
<CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
</DictionaryCompile>
</ItemGroup>
<Import Project="$(MSBuildToolsPath)\Microsoft.CSharp.targets" />
<UsingTask TaskName="ZipDictionary" AssemblyFile="..\LogicTree.DictionaryCompiler\bin\Debug\LogicTree.DictionaryCompiler.dll"/>
<Target Name="BeforeCompile">
<Message Text="Files #(DictionaryCompile)" Importance="high" />
<ZipDictionary DictionaryFiles="#(DictionaryCompile)" OutputDirectory="$(OutputPath)">
<Output TaskParameter="OutputFiles" ItemName="DictionaryOutputFiles" />
</ZipDictionary>
</Target>
<Target Name="FixGetCopyToOutputDirectoryItems" BeforeTargets="GetCopyToOutputDirectoryItems">
<ItemGroup>
<_DictionaryCompile Include="#(DictionaryCompile->'$(OutputPath)Dictionaries\%(FileName).ltdic')" />
</ItemGroup>
<AssignTargetPath Files="#(_DictionaryCompile)" RootFolder="$(MSBuildProjectDirectory)\$(OutputPath)">
<Output TaskParameter="AssignedFiles" ItemName="_DictionaryCompileWithTargetPath" />
</AssignTargetPath>
<ItemGroup>
<AllItemsFullPathWithTargetPath Include="#(_DictionaryCompileWithTargetPath->'%(FullPath)')" Condition="'%(_DictionaryCompileWithTargetPath.CopyToOutputDirectory)'=='Always' or '%(_DictionaryCompileWithTargetPath.CopyToOutputDirectory)'=='PreserveNewest'" />
<_SourceItemsToCopyToOutputDirectoryAlways Include="#(_DictionaryCompileWithTargetPath->'%(FullPath)')" Condition="'%(_DictionaryCompileWithTargetPath.CopyToOutputDirectory)'=='Always'" />
<_SourceItemsToCopyToOutputDirectory Include="#(_DictionaryCompileWithTargetPath->'%(FullPath)')" Condition="'%(_DictionaryCompileWithTargetPath.CopyToOutputDirectory)'=='PreserveNewest'" />
</ItemGroup>
</Target>
A better possible solution would be to
place a common directory in the solution dir and place your common content files there.
in VS, in each project that should share this content, right-click add existing item, browse to the desired item(s), select, click the down-arrow on the add button and select add as link. In the project, you will notice the files are added with a 'shortcut' overlay.
In the project, select the newly added links and right-click->properties and select Build Action: content, Copy To Output Directory: Copy Always.
This is a simple solution to the problem given.
I use this technique for things like SQL scripts and partial config files (using configSource) with great success. This allows me to make changes to these files in a single location with the assurance that they will be propigated throughout the solution.
A more robust solution would be to create a project with embedded resources. This requires a bit more work to manage the content on the receiving end but may be worth it in the long run as having a bunch of loose artifacts flying about can become problematic.
Hope that helps.
A similar solution like the one Sky suggested can be found in my answer to "Is there a way to automatically include content files into asp.net project file?".
It allows to share your content but you must not touch the folder or its content inside VS because this breaks the recursive path.
This approach works best for auto-generated content - you don't have to bother about including new content files to your solution.
And of course you can reuse this in multiple solutions/projects.
We do something similar where we have "...ReleaseBuilds" that reference dlls and content we require for specific projects. Compiling copies everything to the bin debug folder and indeed creates the empty assembly.
Within Visual Studio we have a post-build event in the "...RealeaseBuild" (in project properties) that copies/deletes or run batch files to make sure we have all the files (configs, services etc etc) required and to delete the empty assembly.
HTH
Is there a way to use add-as-link when dragging and dropping source files or entire source trees into a C# project?
Currently, dragging a tree of source files onto a C# project will cause Visual Studio to copy all files to mirror tree below my solution file.
This can be avoided with the the add-as-link option as depicted in the picture below. However, it gets tedious for large trees or when some files in a directory are already part of the project.
Screenshot of the add-as-link functionality in Visual Studio http://jaapsuter.com/images/add_cs_file.jpg
I've looked in Tools->Options, searched the web, and held various magic key combinations when dragging and dropping, to no avail.
I'm tempted to write a script that just globs my .cs files and runs a regular expression over my .csproj file. I'm aware of NAnt, Premake, and other solutions - but I'd like something lightweight.
Although this question has been answered, I thought I'd provide another way, because I found this question while figuring out if it was possible to add linked files in Visual Studio using drag-drop, rather than the cumbersome Add Items dialog box. And while the answer here wasn't what I was looking for, I found out myself:
Holding down CTRL+SHIFT down while drag-dropping, will create linked files. Additionally holding down only CTRL will create copies, but not remove the source file.
What you can also do if you don't find a solution is bind a directory to your project by hand once and let the project find all .cs files in that directory automatically when it loads.
This is easily done by changing your MSBuild file in the following way:
<ItemGroup>
<Compile Include="SomeDirectory\**\*.cs"/>
</ItemGroup>
This will take all .cs files in SomeDirectory and include them to the project. This is very useful if there are often a lot of files added to the project. However, it may break on some machine adding useless files. That's why I would only recommend that on an external project that's not editable in your current workspace.
Probably not what you're asking for, but once I had two .NET applications which I wanted to share a lot of source files and so I placed both Visual Studio solutions in the same directory! It actually works, although I guess that a lot can be said about this approach...
Otherwise the most beautiful way to share code is by placing the shared code in a separate assembly, although this requires quite a bit of extra work if it is not written like that in the first place.