我现在玩的一个技巧(肮脏的把戏?)是将我的数据源(.rds)复制到每个项目中，关闭 Visual Studio，然后在基础文件/文件夹中:

A technique (dirty trick?) I am playing with now is to copy my data source (.rds) into each project, close Visual Studio, then in the underlying files/folders:

• 从我的报表项目中删除复制的.rds(在我的Data Sources 项目中只留下一份)
• 在每个报表项目的项目文件 (Foo.rptproj) 中，更改 My Shared Data Source 中的 Project.DataSources.ProjectItem.FullPath 元素的文本.rds 到 ..\Data Sources\My Shared Data Source.rds

• Delete the copied .rds from my report projects (leaving only the one copy in my Data Sources project)
• In each report project's project file (Foo.rptproj), change the text of the Project.DataSources.ProjectItem.FullPath element from My Shared Data Source.rds to ..\Data Sources\My Shared Data Source.rds

通过这种方式，所有报告项目都引用文件系统上相同的底层文件，因此它们共享一个数据源定义，但每个项目也都有一个本地"共享数据源，因此 Visual Studio 很满意.

This way all reporting projects reference the same underlying file on the filesystem, so they share a single data source definition, but each project also kind of has a "local" shared data source, so Visual Studio is kept happy.

关于源代码控制:仍然只有一个 .rds 的副本被签入，所以我们不会用大量令人讨厌的重复项污染代码库；可以检入对 .rptproj 文件的更改，因此我们不会强迫开发人员进行不自然的源代码控制(选择性部分提交等)以维护一个健全的主副本.

Regarding source control: there is still only one copy of the .rds checked in, so we're not polluting the code base with lots of icky duplicates; the changes to the .rptproj files can be checked in, so we're not forcing developers into unnatural source-control gymnastics (selective partial commits etc.) to maintain a sane master copy.

每个报表项目都会尝试部署这个数据源，虽然我已经禁止覆盖服务器上现有的数据源，所以这没什么大不了的...我想如果我打算覆盖服务器的数据源定义，我是否用相同的 .rds 覆盖它一次或十次并不重要.

Each reporting project will try to deploy this data source, though I've forbidden the overwriting of existing data sources on the server, so it's not too big a deal . . . and I suppose if I intended to overwrite the server's data source definition, it wouldn't really matter whether I overwrote it once or ten times with the same .rds.

免责声明:这仍然是一个实验.我还没有在实践中使用这种技术的经验，所以我不能真正推荐它.

Disclaimer: this is still an experiment. I don't have experience using this technique in practice yet, so I can't go so far as to actually recommend it.