We Keep Coding

Microsoft .NET DLL in PublicAssemblies folder being deployed during build

We have a pretty large solution with several projects where a few reference the library, Microsoft.bcl.AsyncInterfaces.dll, 6.0.0.0, Public Key Token cc7b13ffcd2ddd51. Scanning the output file during the build, I see that the reference to 6.0.0.0 DLL is being copied out to the build folder, but toward the end, the 5.0.0.0 DLL is being copied to the build folder.
The source of this copy is in VS is below
Copying file from "C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\Common7\IDE\PublicAssemblies\Microsoft.Bcl.AsyncInterfaces.dll" to ...
The VS file is version 5.0.0.0. I don't get it. There is literally nothing referencing this 5.0.0.0 DLL in VS and I don't know how it got there. If I delete this DLL, the build does what I think it should do, but my VS breaks.
Could this DLL be coming from an extension, and if so, why is it being used in my build?

Setting the msbuild logging to "diag" was the key. Found out that the DLL in question was required by another library/DLL and that was forcing the usage of 5.0.0.0, even though the projects were trying to use 6.0.0.0. Changed all of the 6.0.0.0 references to 5.0.0.0 and all is good.

How to Load .csproj file into .NET Core 3.0 using MSBuild NuGet

I have a very simple console project:
class Program
{
static void Main(string[] args)
{
var project = new Project(
"FishStory.csproj",
null,
null,
new ProjectCollection());
Console.ReadLine();
}
}
This is a .NET Core 3.0 console application, and it has Microsoft.Build (16.4.0) NuGet package referenced.
The .csproj file FishStory.csproj is found (I don't get an exception that the .csproj is missing), but I do get the following error.
Microsoft.Build.Exceptions.InvalidProjectFileException:
'The imported project
"C:\Users\vchel\source\repos\ForDave\ForDave\bin\Debug\netcoreapp3.0\Microsoft.CSharp.targets" was not found.
Confirm that the expression in the Import declaration "C:\Users\vchel\source\repos\ForDave\ForDave\bin\Debug\netcoreapp3.0\Microsoft.CSharp.targets" is correct, and that the file exists on disk. C:\Users\vchel\source\repos\ForDave\ForDave\bin\Debug\netcoreapp3.0\FishStory.csproj'
I'd expect that such a simple MSBuild test would "just work", but it seems like I'm missing something. What can I do to load this .csproj file?

I have catched the same exception while I have tried to load a project targeted to netcore31 platform.
But after that I have installed
Microsoft.Build.Utilities.Core(16.5.0)
Microsoft.Build (16.4.0)
nuget packages, there is no more the exception. The project is loaded successfully.
Maybe, it will help someone more.

It seems the NuGet package adds the necessary .dlls to use the Project object, but the various project types must have .target and .props files which are used when the Project .csproj is loaded.
To load my specific project, I had to add the following files to the output directory. I accomplished this by placing the files in my project and marking them as Copy if Newer.
I added the following files:
Microsoft.Common.targets
Microsoft.CSharp.targets
Microsoft.NETFramework.props
Microsoft.NETFramework.targets
In my case the .csproj is a MonoGame project, so I also had to add:
MonoGame.Build.Tasks.dll (not sure if I needed this or not)
MonoGame.common.props
MonoGame/v3.0/MonoGame.Content.Builder.targets
To add these files so they are copied to the output folder:
Add the file to your project (for .NET Core you just have to add the file to the directory)
Right-click on the file in the Solution Explorer and select Properties
Set the Copy to Output Directory to Copy if newer
I pulled the targets/props/.dll files from:
C:\Windows\Microsoft.NET\Framework64\v4.0.30319
C:\Program Files (x86)\MSBuild\MonoGame\v3.0
I am guessing that other project types (such as an Android Xamarin project) may require different .targets files, which can be found here if using Visual Studio 2019 Community:
C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Xamarin
Finally, I also had to manually add the NuGet Package Microsoft.Build.Utilities.Core. Not sure why that wasn't automatically added when adding Microsoft.Build

Running Fortify on .dll files as well as .cs

.NET version of existing question Can I run fortify on .jar files instead of .java?
My team is using Fortify 5.15.0.0060. We are scanning our .NET project in Visual Studio, and project settings shows the following command line arguments:
-vsversion 10.0 "-b" "project" "-machine-output" "-scan" "-f" "C:\Users\user\AppData\Local\Fortify\VS2010-3.80\project\Scan.fpr" "-format" "fpr"
This highlights issues in our .cs source code files, but does not appear to look at the DLLs that form part of our solution (and which are copied to our output directory along with our binaries). For many of these libraries we do not have access to .pdb files, but were hoping that Fortify would be able to do a limited amount of scanning anyway.
Is it possible to add a command line argument to include DLL files, with/without PDB files?

When it comes to .Net, Fortify can only scan assemblies that have a .pdb because it uses ildasm.exe to decompile the assembly and then it uses the .pdb to match to the source files. Unfortunately there is no way for you to scan these extra assemblies.
If you have the .pdb files, you can have Fortify scan them, however you may not see the full source in your results. To include these assemblies, you need to specify them in your Translation options. If you are doing this all from the command line, then this is how you would do it:
sourceanalyzer -b project -vsversion 10.0 projectPath\Additional.Assembly.1.dll projectPath\Additional.Assembly.2.dll projectPath\Additional.Assembly.3.dll
sourceanalyzer -b project -scan -f MyResults.fpr
If you have not yet updated your Fortify version, I would highly recommend that you do so.

Solution fails to build when using OutDir with MsBuild

We have several .Net 4.0 solutions that all depend on assemblies built by one specific solution, our Server.sln (I guess Shared.sln would have been a better name for it). Our build process first builds the Server.sln to a Binaries directory using the MsBuild OutDir parameter, and then subsequent solutions to subdirectories (e.g. Binaries\Client, Binaries\Web, etc.), again using the OutDir parameter to specify the path to the appropriate subdirectory. This allows us to easily publish our separate applications to different places. This works fine for all of our solutions, except a new API.sln that we created.
Like the other solutions, API.sln references some DLLs built by the Server.sln, but the actual compile error I get is that one project (we'll call it Project1) cannot find a reference to Project2. Project1 and Project2 are both projects in API.sln, and Project1 references Project2 via a project references; not a dll file reference. Also, Project2 does not have any external dependencies either; the only references it has are to System, System.Core, and System.Runtime.Serialization.
Everything works if I set the OutDir to just be the Binaries directory, but I don't want to do that as then all of the API.sln assemblies get mixed with ALL of the Server.sln assemblies, which makes deploying just the API.sln assemblies harder. When I set the OutDir to be Binaries\API then I get the build error saying that:
The name '[Project2 Class Name]' does not exist in the current context [Path to Project1.csproj]
I checked though and the Project1.dll and Project2.dll assemblies are both getting created to the Binaries\API directory, so I'm not sure why this error is getting generated. Our TFS build server has this problem, but I can also recreate it on my local machine by calling MsBuild on the .slns with the same parameters. Any ideas?
Here are the two msbuild commands that I'm using to actually do the builds:
Build the Server.sln:
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\MSBuild.exe /nologo "C:\PlatformAPIBuild\BuildProcessTests\Sources\RQ4.Server.sln" /nr:False /fl /flp:"logfile=C:\PlatformAPIBuild\BuildProcessTests\Sources\RQ4.Server.log;encoding=Unicode;verbosity=normal" /p:SkipInvalidConfigurations=true /p:ReferencePath=C:\PlatformAPIBuild\BuildProcessTests\Binaries /p:OutDir="C:\PlatformAPIBuild\BuildProcessTests\Binaries\\" /p:Configuration="Release" /p:Platform="Any CPU" /p:VCBuildOverride="C:\PlatformAPIBuild\BuildProcessTests\Sources\RQ4.Server.sln.Any CPU.Release.vsprops"
Then build the API.sln:
C:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe /nologo "C:\PlatformAPIBuild\BuildProcessTests\Sources\IQ.Platform.PublicAPI.sln" /nr:False /fl /flp:"logfile=C:\PlatformAPIBuild\BuildProcessTests\Sources\IQ.Platform.PublicAPI.log;encoding=Unicode;verbosity=normal" /p:SkipInvalidConfigurations=true /p:ReferencePath=C:\PlatformAPIBuild\BuildProcessTests\Binaries /p:OutDir="C:\PlatformAPIBuild\BuildProcessTests\Binaries\Platform.PublicAPI\\" /p:Configuration="Release" /p:Platform="Any CPU" /p:VCBuildOverride="C:\PlatformAPIBuild\BuildProcessTests\Sources\IQ.Platform.PublicAPI.sln.Any CPU.Release.vsprops"
And here is the log file from the API.sln build. You'll notice that it has errors like,
Warning as Error: Reference to type 'IQ.Platform.Framework.WebApi.Model.Hypermedia.AccessControl' claims it is defined in 'c:\PlatformAPIBuild\BuildProcessTests\Binaries\Platform.PublicAPI\IQ.Platform.Framework.WebApi.Model.dll', but it could not be found
but the file it says isn't there, is actually there when I look for it after the build fails, and you can see that one of the first things it does at the top of the log file is copy that assembly to that path, so I'm not sure why it can't find it. The IQ.Platform.Framework.WebApi.Model is the Project2 in my discussion above.
Here is the log file from the API.sln build with all of the Test projects removed, so that only one error remains, which will hopefully make looking through the log file a little easier. And here is the same log, but with diagnotic verbosity.

How do you determine what executable and DLL’s a C# Visual Studio project produces?

How do you determine what executable and DLL’s a C# Visual Studio project produces?
In Visual Studio 2010, where do you go to see what the name of the executable that a project produces.

A C# project will produce just one assembly output (DLL or EXE). Additional assemblies will be included from references that are not installed in the GAC. For instance, if you add a reference to another project in the solution, it will copy that project's output assembly to the current project's bin folder.
Check the bin folder after build to see what was generated and included. e.g. <project folder>/bin/Debug

I think it's the <AssemblyName> section in the .csproj file. Combined with the <OutputType> section to determine the file extension.