We are currently trying to implement unit/integration tests (Dynamics 365 onprem).
For this we need to use dummy/fake dll that contains http requests towards ESB. I tried solving this with creation of 2 .sln files. In deployment one I reference actual .csproj while in test one I reference fake one. Only difference between them is path towards them while names stayed unchanged (project/company.crm.esb/crm.esb.csproj and project/test.crm.esb/crm.esb.csproj).
After this I changed .csproj project references to use wildcard for the middle folder (project/**/crm.esb.csproj) and now when I try to load fake sln I get error that actual crm.esb.csproj is missing while when I load actual .sln vs gives error that it cannot load fake crm.esb.csproj
Does VS store some kind of metadata that breaks wildcards like this and is there any workaround for this?
Found the problem:
When I write wildcard it tries to load both fake and non faked csproj
Is there any way to make csproj see only folder structure made in sln file?
There is no such thing as a solution folder structure (what you see as “folders” in the solution are just names used for grouping). MSBuild files follow your file system so a wildcard will include everything it sees below that point.
In addition, I don’t think that using globbing (that’s how they call wildcards in MSBuild jargon) for project references is a good idea.
C# devs
null reference exceptions