I found something called "MyProjectName.deps.json" in the "bin" directory. But if i delete the "bin" directory and build my project again it gets created again. Where does VisualStudio pull this data from (which packages should be included in the project)?
This is based upon the obj\project.assets.json file (generated by NuGet restore) which defines inputs to the build logic that are used for the generation of the .deps.json file, along with other references from the project file.
Related
How can I <Import> a .targets file that is included in <PackageReference>d NuGet package in a non-SDK-style web application project that targets .NET 4.7.2?
Background
The web application project is not an SDK-style project. It references a class library project in the same solution. This class library project is an SDK-style project. It has a package reference to Microsoft.Data.SqlClient version 4.1.0, which depends on Microsoft.Data.SqlClient.SNI.runtime 4.0.0. The latter contains native binaries which are automatically copied to the bin directory of the project.
The native binaries are not copied to the bin directory of the web application project. This is probably because of this:
SNI is the native C++ library that SqlClient depends on for various network operations when running on Windows. In .NET Framework applications that are built with the MSBuild Project SDK, native DLLs aren't managed with restore commands. So a ".targets" file is included in the "Microsoft.Data.SqlClient.SNI" NuGet package that defines the necessary "Copy" operations.
The included ".targets" file is auto-referenced when a direct dependency is made to the "Microsoft.Data.SqlClient" library. In scenarios where a transitive (indirect) reference is made, this ".targets" file should be manually referenced to ensure "Copy" operations can execute when necessary.
Recommended Solution: Make sure the ".targets" file is referenced in the application's ".csproj" file to ensure "Copy" operations are executed.
Source
Not sure what "built with the MSBuild Project SDK" means exactly, but I think my scenario qualifies.
Now I'm trying to implement the recommended solution, but I cannot get it to work.
What I did
Step 1: add package reference to Microsoft.Data.SqlClient.SNI version 4.0.0:
<PackageReference Include="Microsoft.Data.SqlClient.SNI">
<GeneratePathProperty>true</GeneratePathProperty>
<Version>4.0.0</Version>
</PackageReference>
I added <GeneratePathProperty> because of step 2 below. According to the documentation this should make a property available that can be used to refer to files in the package:
Sometimes it is desirable to reference files in a package from an MSBuild target. In packages.config based projects, the packages are installed in a folder relative to the project file. However in PackageReference, the packages are consumed from the global-packages folder, which can vary from machine to machine.
To bridge that gap, NuGet introduced a property that points to the location from which the package will be consumed.
Step 2: import the targets file:
<Import Project="$(PkgMicrosoft_Data_SqlClient_SNI)\build\net46\Microsoft.Data.SqlClient.SNI.targets" Condition="Exists('$(PkgMicrosoft_Data_SqlClient_SNI)\build\net46\Microsoft.Data.SqlClient.SNI.targets')" />
You can see that the package contains this targets file using the NuGet package explorer (link). The PkgMicrosoft_Data_SqlClient_SNI property is named according to the documentation (linked above) and based on their example:
MSBuild properties and package identities do not have the same restrictions so the package identity needs to be changed to an MSBuild friendly name, prefixed by the word Pkg.
Step 3: verify the tool versions on our agent:
MSBuild 16.11.2.50704 (installed on the agent C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\MSBuild\Current\bin)
NuGet 6.1.0.106 (installed via a pipeline task)
According to the documentation linked above, these fulfil the minimum requirements (MSBuild 16 and NuGet 5).
Step 4: run nuget restore on our build agent and then build the project using the Azure DevOps MSBuild#1 task with msbuildArguments: '/t:Build'.
Step 4: collect output and publish as an artifact.
Outcome:
The SNI files are not present in the output. When building locally with MSBuild 17.0.0.52104 (installed in 'C:\Program Files (x86)\Microsoft Visual Studio\2022\BuildTools\MSBuild\Current\bin') I do see the SNI files.
I am using a NuGet package which has an XML documentation file.
But when I include the package in a .NET Core 2.2 app, the comments are not available with IntelliSense.
Is there something I'm missing either in the package or in my app to be able to see the documentation with IntelliSense?
Using VisualStudio 2017, Windows 10.
Update for Clarity
The NuGet package is a .NET Standard 1.3 class library. In Visual Studio when I build the project, I include the options to generate the package and documentation file. In the project file, I see the following PropertyGroup:
<PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Release|AnyCPU'">
<DocumentationFile>C:\Users\[username]\[local path]\CommonEntities\CommonEntities\CommonEntities.xml</DocumentationFile>
</PropertyGroup>
When I open the package, I can see in the lib/netstandard1.3/ directory that CommonEntities.xml is included along with MakanalTech.CommonEntities.dll.
But, I'm wondering why the xml file has dropped the full name from MakanalTech.CommonEntities.xml as it is in the project to just CommonEntities.xml in the package. Maybe this is the cause of the issue?
The issue is then when I include the package as a dependency in another project, none of the XML comments/documentation are visible. So I can't hover over a type to see its description, and if I peek definition none of the comments/documentation are in the definition.
Class Library Product
https://imgur.com/zbE7ngM (can't post images yet)
Peeking at definition from other project:
https://imgur.com/pwmvpX7
Finally found the issue from this post. This seems quite buggy from Visual Studio 2017 not to handle this correctly and automatically.
In the .csproj file, I removed <DocumentationFile>[filepath-to-xml]</DocumentationFile> and added <GenerateDocumentationFile>true</GenerateDocumentationFile>.
I then repacked the library, cleared my nuget cache, and rebuilt the new project where it's included, and now I have all the XML documentation visible.
NuGet package XML documentation not visible in .NET Core 2.2 app
Just like what have you found that "in the lib/netstandard1.3/ directory that CommonEntities.xml is included along with MakanalTech.CommonEntities.dll.", the .xml file in the lib folder, then according to the document From a convention-based working directory:
Only the .dll file will be added as reference, .xml file will be copied to the project folder. That is the reason why the XML documentation not visible in .NET Core 2.2 app.
Besides, since you are using .netstandard project, .xml file will blocked be copied to the project folder automatically by the nuget issue 4837.
To resolve this issue, we have to create the .nuspec file with option contentFiles to include the .xml file and add this file to the project, please check the detail info from other thread.
But if you do not want to manually edit the .nuspec every release, you can use a post-build event to pack the nuget package automatically,like:
nuget pack "$(.NuspecFilePath)\xxx.nuspec"
Or you can add the .xml file to the project manually from the package directly, that package is in the path: C:\Users\<UserName>\.nuget\packages.
Hope this helps.
After using TeamCity, my build process is Visual Studio (sln) -> NuGet Pack. Everything builds fine and the artifact is created. But the artifact has every single file, include the .vbproj, .vb files, the classes folder which only holds .vb files.
Is there a way to turn a setting on to create the artifact which doesn't have all the .vb files etc due to them being compiled in the .dll?
For anyone wondering, I just excluded the .vb files in the nuspec
Have you considered using Octopack to package the nuget. It is smart enough to include all the required files into the package and will not require a custom nuspec file that you would need to source control and manage for any future changes.
IMO custom nuspec file should be used only if you have a very specific requirement such as if the target directory is different.
(mark as content and copy always for the files that you want to include)
I converted a VS2010 ASP.Net MVC3 project to VS2013 MVC4. Now when I publish, it is copying the contents of my project to the bin folder.
I can't understand what I did to make it do this..How do I fix it so it doesn't do it?
Your files are incorrectly set to copy to the output folder (\bin) during build. Make sure that the Copy To Output setting on each file is set to Do Not Copy.
Normally, you don't need to copy much of anything to your bin folder. When publishing, all of the content pages (*.aspx, *.html, *.css, etc) will get picked up by publish just by existing in the project. This is determined by the Build Action being set to Content. (Note: you can exclude files by setting the Build Action to None)
For code files, there's 2 ways it could go. in a Web Application project (which MVC is) most code files, such as controllers, models, or code behind files in WebForms, are compiled into your site's DLL already. These have Build Action = Compile, meaning they get compiled up front and don't need to be included in the publish. The exception to this is files in App_Code, which are deployed to your site (Build Action = Content) and compiled at runtime. You can also choose to pre-compile your site in the publish settings (Settings -> File Publish Options -> Precompile during publishing), which will process the App_Code files automatically (i.e. you can leave them as Build Action = Content and VS will compile them and publish the output instead).
I am newbie to TFS.
I am trying to automate process of build upon checking in the code in TFS.
I setup a Controller and an Agent. I created a new build definition and set a "build" and "drop" folder on c:.
I check in the code, expecting to see the generated dll files in "drop" folders. There's none, just "logs" folder. The "binaries" folder in "build" folder is also empty. Apparently the binaries are not being generated at all. How can I have MSBuild to generate the dll files?
They are generated when I compile the website locally on my development machine under "bin\" folder. The solution is comprised of two separate projects: "core" and "web" where "core" is referenced within "web".
Any thoughts?
What is the Summary showing of your build that ran? Or are there errors in your build? You can check the log of the build by opening the build in Visual Studio and then click View Log.