1

I am using Visual Studio 2019 and am upgrading a .vbproj file to use some more modern features - I think the initial solution/project may have been built as far back as VS 2008. I'm converting the masses of explicit file includes into one wildcard to pull in all my files:

   <ItemGroup>
      <Compile Include="Src\**\*.vb" />
   </ItemGroup>

This works great, I can see all the files inside Visual Studio's project explorer. However, when I build the project, this wildcard gets expanded out and every source file is named, like this:

   <ItemGroup>
      <Compile Include="Src\Code\File1.vb" />
      <Compile Include="Src\Code\File2.vb" />
      <Compile Include="Src\Code2\File1.vb" />
   </ItemGroup>

This doesn't happen until I build the project, I can load Visual Studio with no issues and the project file remains untouched.

I'm doing this because of having a few problems merging these files across some refactoring branches where many files are deleted, so this method would be much easier.

Can I prevent Visual Studio from doing this?

LoLance
  • 25,666
  • 1
  • 39
  • 73
Steven Sproat
  • 4,398
  • 4
  • 27
  • 40
  • 1
    Hmm, that's annoying. Could be something VB-specific: we do the same with C++ files and that works ok. – stijn Feb 04 '20 at 20:58
  • 1
    An idea: VS will as far as I know only ever modify the project file itself. So if you define your ItemGroup in a separate file which you then Import from the main .vbproj file you should be good. – stijn Feb 05 '20 at 08:54

2 Answers2

1

Can I prevent Visual Studio from doing this?

Actually it should work, and it does work with C# and VB.net projects in my side with latest VS2019 16.4.4.

1.My guess is that since your project comes from old VS2008, the format of your project file(xx.vbproj) is quite different from new project file format in VS2019 so that VS2019 project system can't recognize it well.

PS: For this, you can create one new VB .net fx project in VS2019 to confirm if what you want should work for VB projects. Also I suggest you can create new VB empty project, and move your source files in new project to do the mgration.

2.Another possible cause may have something to do with the order how to copy and move the files.

For me, I create a new VB project=>In project folder create Src folder=>In Src folder create Code folder=> In Code folder create Test1.vb and Test2.vb with simple code. Then use the ItemGroup to contain those files, and it works well all the time no matter during development or after build.

(You may check if you use similar steps, or you may paste the files in Solution Explorer before editing the xx.vbproj?)

Hope it makes some help and if I misunderstand your question, feel free to correct me :)

LoLance
  • 25,666
  • 1
  • 39
  • 73
  • I think that I've worked around it by following the upgrade path here - https://natemcmaster.com/blog/2017/03/09/vs2015-to-vs2017-upgrade/ (changing root element to ) I have removed my wildcard includes as it includes these by default. – Steven Sproat Feb 05 '20 at 12:31
  • 1
    That's guide for .net core which available in VS2017 and VS2019. I'm not sure why you want to migrate one VS2008 project to .net core, but if that helps to resolve your issue, please consider adding your answer with details later and that will help others with similar issue. Just a reminder :) – LoLance Feb 06 '20 at 08:27
  • 1
    I don't think it's dotnet core specific, you can still target the .NET framework. I've also converted to using s as opposed to the older packages.config. All in, my .vbproj has dropped from 2100+ lines to 300 :) – Steven Sproat Feb 06 '20 at 10:23
1

I have managed to work around this by upgrading the project file to a Visual Studio 2017/2019 type. The following guide was really handy: https://natemcmaster.com/blog/2017/03/09/vs2015-to-vs2017-upgrade/

  • Replacing the root project XML element w/ <Project Sdk="Microsoft.NET.Sdk">
  • Removing the wildcard include I specified in the original post -- Visual Studio matches this glob pattern by default with the new project style
  • Converted packages.config NuGet references over to use <PackageReference>s

Am pretty happy with how this has turned out :)

Steven Sproat
  • 4,398
  • 4
  • 27
  • 40