Building a nuget .Net Framework web application package using msbuild and TeamCity? - msbuild

What is the method to create a web application nuget package with TeamCity?
I'm totally confused after .NET became a thing.
What I'm attempting to do, is to create a nuget package with a .Net Framework 4.8 webapplication in it.
The ways things worked before, seems to be outdated or deprecated.
In TeamCity, the meta runners that were used previously are either deprecated or not functioning very well.
When I'm googling f.ex. msbuild
https://learn.microsoft.com/en-us/nuget/create-packages/creating-a-package-msbuild
I get stuff about .Net Core and .Net Standard, nothing about .Net Framework. And the stuff is often 10 years old or more.
I might have gone stupid after how nuget works in .NET, since everything is tied to projects and you can actually avoid having code shipped (the cs files) with the web application.

The closest I've gotten so far, is by making a comprehensive .nuspec file, then run in the project directory of the web application after the project has been built with all necessary dependencies.
However, the build output will log warnings:
WARNING: NU5100: The assembly 'bin\Antlr3.Runtime.dll' is not inside the 'lib' folder and hence it won't be added as a reference when the package is installed into a project. Move it into the 'lib' folder if it needs to be referenced.
The nuget pack command
nuget pack <path to nuspec file>
The nuspec file:
<?xml version="1.0" encoding="utf-8"?>
<package>
<metadata>
<id>MyPackageId</id>
<version>1.0.0.0</version>
<title>My application title</title>
<authors>my authors</authors>
<requireLicenseAcceptance>false</requireLicenseAcceptance>
<description>Some description</description>
<releaseNotes>Summary of changes made in this release of the package.
</releaseNotes>
<copyright>My copyright</copyright>
<tags>framework application</tags>
</metadata>
<files>
<file src="bin\**\*.*" target="bin"/>
<file src="Content\**\*.*" target="Content"/>
<file src="Resources\**\*.*" target="Resources" exclude="**\*.cs"/>
<file src="Scripts\**\*.*" target="Scripts" />
<file src="Views\**\*.*" target="Views" />
<file src ="favicon.ico" target=""/>
<file src ="Global.asax" target=""/>
<file src ="Log4Net.config" target=""/>
<file src ="StrongNameKeyFile.snk" target=""/>
<file src ="Web.config" target=""/>
</files>
</package>
Rather comprehensive ...

Related

Unable to install the artifacts after getting generated from msbuild

Currently my application is running in .net framework and .net standard 2.0 which is works fine and all the artifacts(packages) are getting installed correctly , due to some requirement we have migrated one project into .net 6 windows after that the artifacts are not getting install. it shows the log message as fails to install .
Wix setup for .net framework and .net standatd application
<Component Id="AdminService_Logic_dll" Guid="{2677C0B4-1560-8CD9-568C-6097FF926C3A}">
<File Id="AdminService_Logic_dll" Name="AdminService.Logic.dll" KeyPath="yes" Assembly=".net" AssemblyManifest="AdminService_Logic_dll" AssemblyApplication="AdminService_Logic_dll" DiskId="1" Source="$(var.SourceDir)\AdminService.Logic.dll" />
</Component>
Wix setup for .net net6.0-windows application
<Component Id="TestCase_exe" Guid="{0D8D84F1-FFC5-28F6-F1D7-8620DA17313B}">
<File Id="TestCase_exe" Name="TestCase.exe" KeyPath="yes" DiskId="1" Source="$(var.SourceDir)\TestCase.exe" />
</Component>
since .net 6 doesn't support AssemblyManifest, Assembly attribute we have removed . currently my wix project's ProductVersion is 3.10 .
could you please guide me where the setup has wrong so that the artifacts (packages) are not getting install after migrate one application into .net 6

Nuget packing not including dependncies in right way

I have a C# library, let say "Utilities" that uses Log4net as dependency, I am using .net framwork 4.6.1, I finished developeing this library and do a nuget pack Utilities.projcs and then push this package.
While I'm try to use this Utilities in another project that which is an asp.net core "2.1" project, I got this exception
**Method not found: 'log4net.ILog log4net.LogManager.GetLogger(System.String)'.**
System.MissingMethodException
HResult=0x80131513
Message=Method not found: 'log4net.ILog log4net.LogManager.GetLogger(System.String)'.
Source=Utilities
StackTrace:
at Utilities.Logging.MyLogManager.GetLogger(String loggerKey)
My Utilities nuget spec file
<?xml version="1.0"?>
<package >
<metadata>
<id>Utilities</id>
<version>1.2.0</version>
<title>Internal Utilities</title>
<authors>My Team</authors>
<owners>My Team</owners>
<requireLicenseAcceptance>false</requireLicenseAcceptance>
<description>This dll contains parsers,loggers and other functionalities that is commonly used.</description>
<releaseNotes>Rlease notes</releaseNotes>
<copyright>Copyright 2020</copyright>
<tags>Utilities</tags>
<dependencies>
<dependency id="log4net" version="2.0.8" include="all"/>
</dependencies>
</metadata>
<files>
<file src="bin\Debug\log4net.dll" target="" />
<file src="bin\Debug\log4net.xml" target="" />
<file src="bin\Debug\Utilities.dll" target="" />
</files>
</package>
Any ideas to solve this, I spent the last couple of days to solve it but no luck
NOTE: When I add Reference manually by location in my pc (My library + Log4net) it works fine!!
Create class library in .net standard.
For more info about .net standard visit https://learn.microsoft.com/en-us/dotnet/standard/net-standard
How to create .net standard class library -> https://learn.microsoft.com/en-us/dotnet/core/tutorials/library-with-visual-studio?tabs=csharp
How to create .net standard Nuget -> https://learn.microsoft.com/en-us/nuget/quickstart/create-and-publish-a-package-using-visual-studio?tabs=netcore-cli
this image will help you understand the concept behind shared libraries.

WIX Win64="no" no effect

I have following component in installer
<Component Id="my.dll" Guid="*" Win64="no">
<File Id="my.dll" Name="my.dll" KeyPath="yes" ReadOnly="yes" DiskId="1" Source="$(var.TargetDir)/my.dll" />
</Component>
In visual studio configuration manager for solution platform x64 the installer project is set to x64.
When building x64, the build is still failing on this part, looking for my.dll although Win64 is set to "no".
In the wixproj I have manually added by copying the x86 section:
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|x64' ">
<OutputPath>bin\$(Configuration)\</OutputPath>
<IntermediateOutputPath>obj\$(Configuration)\</IntermediateOutputPath>
<DefineConstants>Debug</DefineConstants>
</PropertyGroup>
Did same for 'Release|x64'. and also tried removing following:
<Platform Condition=" '$(Platform)' == '' ">x86</Platform>
and also changing the x86 to x64 but this did not help.
Why is x64 build still regarding this line although Win64="no"?
Reference: Using Project References and Variables.
TargetPath: Maybe try to use $(var.ProjectName.TargetPath) instead of $(var.TargetDir)/my.dll. I think that is what is wrong. The TargetPath will be the whole path with file name for what you build. See the above "Reference" link for all these parameters (preprocessor variables).
Extra Notes: A couple of further things:
Notice the ProjectName section: if your Visual Studio project is called MyLittleProject, then you should add: $(var.MyLittleProject.TargetPath).
The Win64="no" attribute for the Component element in WiX files affects where the file is installed on the target system where end-user installation happens, not where the Visual Studio build files are located on disk after successful build:
Program Files (x86) (32-bit) or Program Files (64-bit)
Windows (64-bit) or SysWOW64 (32-bit, yes amazingly)
Quick Sample: This is from memory and probably not very good, but here is a sample of Preprocessor variables in action (got this long answer on such constructs):
<?if $(var.MyProjectName.Platform) = "x64" ?>
<Component>
<File Source="C:\Test\Test1.exe" />
</Component>
<?endif?>
<?if $(var.MyProjectName.Platform) = "Win32" ?>
<Component>
<File Source="C:\Test\Test2.exe" />
</Component>
<?endif?>
<Component>
<File Source="$(var.MyProjectName.TargetPath)" />
</Component>
Make sure the configuration is set to rebuild all projects including your WiX project. There could be unexpected exclusions. Notice how platform might say Win32 versus x64 for platforms (instead of the perhaps expected x86) - common errors. Inspect the compiled MSI. Also be sure to set a proper project build order (manipulate project dependencies).
sys.BUILDARCH: There is also the sys.BUILDARCH built-in variable, which has me a little confused to be honest. I have not used it. Search for it here: Preprocessor. And github.

Create NuGet package for C++/CLI (mixed) assembly

I have created a C++/CLI (mixed) assembly which has a managed wrapper class around some unmanaged C++ code. The managed part targets .NET 4.6.1, I got a file entry.cpp with just this line to do that:
[assembly:System::Runtime::Versioning::TargetFrameworkAttribute(L".NETFramework,Version=v4.6.1", FrameworkDisplayName = L".NET Framework 4.6.1")];
When I now manually include the compiled assembly in a .NET 4.6.1 project I can use the managed class as expected.
This project can be build four ways: x86 or x64 as either debug or release build. It has no managed dependencies.
Now I want one (or if required multiple) NuGet packages which I can upload to my feed and use the wrapper assembly easily in every .NET 4.6.1 compatible project I would like. How do I achieve this?
So far I tried two approaches:
First, I created a .autopkg file which is according to this blog post the way to provide native DLLs. The files section of that file looks like this:
files {
// include: { *.h };
[x86,v120,release] {
symbols: { ..\Release\*.pdb; }
bin: { ..\Release\*.dll; }
};
[x86,v120,debug] {
symbols: { ..\Debug\*.pdb; }
bin: { ..\Debug\*.dll; }
};
};
This process results in three .nupkg files which I can upload to my feed. But when I try to install that package to a .NET 4.6.1 project I get this error message:
Could not install package 'MyCppCliWrapper.redist 1.0.0.2'. You are trying to install this package into a project that targets '.NETFramework,Version=v4.6.1', but the package does not contain any assembly references or content files that are compatible with that framework. For more information, contact the package author.
So I rethought if I should not use the way for managed assembly to create the .nupkg because the assembly has a managed class I want to use from managed code. I created a .nuspec (using nuget spec) and provided the metadata. Then I try to create my package like this:
nuget pack MyCppCliWrapper.nuspec -Prop Configuration=Release -Prop Platform=x86 -Build
But that results in a package which contains the whole project with all source files and temporary files, just like a zip file of that folder.
Obviously there is also missing the meta information about targeted framework.
When I try to use the project file to create the package (like with C# assemblies) this fails too:
Please specify a nuspec, project.json, or project file to use
The C++ project files, .vcxproj, seem to be unsupported by NuGet (I am using the NuGet 3.5.0.1938 command line utility).
Will I need to build manually and provide all files in the files section of the .nuspec? If yes, how would he know from this line which DLL is for which .NET framework plus platform?
<file src="bin\**\*.dll" target="lib" />
I believe Hans Passant is right, this is just a regular managed nuget package but the packager does not handle the .vcxproj files so I made up my own .nuspec:
<?xml version="1.0"?>
<package >
<metadata>
...
</metadata>
<files>
<file src="readme.txt" target="" />
<file src="bin\Win32\Release\*.dll" target="lib\net461" />
<file src="bin\Win32\Release\*.pdb" target="lib\net461" />
</files>
</package>
The package generated this ways works.
There is one question remaining: This way, do I have to do two packages, one for 32bit and one for 64bit - or is it possible to include them in one package (which I would prefer) and have the consuming project use one or another depending on the target architecture (any-cpu is mostly 32bit)?
I don't know if this could still help you, but I've managed to pack both x64 and x86 C++ code, and a C# wrapper that was compiled on AnyCPU.
On My C# project, I have two Platforms: "x86" and "x64".
On my Nuget folder, I have the following structure:
\Project
\Project.1.0.nuspec
\build
\x64
\*.dll
\*.pdb
\x86
\*.dll
\*.pdb
\Project.targets
\lib
\net452
\Wrapper.dll
\Wrapper.pdb
Project.nuspec:
<?xml version="1.0" encoding="utf-8"?>
<package xmlns="http://schemas.microsoft.com/packaging/2011/08/nuspec.xsd">
<metadata>
<id>Project</id>
<version>1.0</version>
<authors>nilsonneto</authors>
<owners>nilsonneto</owners>
<requireLicenseAcceptance>false</requireLicenseAcceptance>
<description>Example.</description>
<references>
<reference file="Wrapper.dll" />
</references>
</metadata>
<files>
<file src="build\Project.targets" target="build\Project.targets" />
<file src="build\x64\**" target="build\x64" />
<file src="build\x86\**" target="build\x86" />
<file src="lib\net452\Wrapper.dll" target="lib\net452\Wrapper.dll" />
<file src="lib\net452\Wrapper.pdb" target="lib\net452\Wrapper.pdb" />
</files>
</package>
Project.targets:
<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<ItemGroup>
<NativeLibs Include="$(MSBuildThisFileDirectory)\$(Platform)\*.*" />
<Content Include="#(NativeLibs)">
<Link>%(RecursiveDir)%(FileName)%(Extension)</Link>
<CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
</Content>
</ItemGroup>
</Project>
Notice the $(Platform), which is where the name of the Platform being build on Visual Studio will be placed, which is why I separated the C++ DLLs in folders with the same name as the Platforms in Visual Studio.
And according to the documentation (https://learn.microsoft.com/en-us/nuget/create-packages/native-packages), all native DLLs have to be placed in the \build directory.
Native NuGet packages targeting native then provide files in \build, \content, and \tools folders; \lib is not used in this case (NuGet cannot directly add references to a C++ project). A package may also include targets and props files in \build that NuGet will automatically import into projects that consume the package. Those files must be named the same as the package ID with the .targets and/or .props extensions.
So, just adjust the folder names based on the Platforms you support on the .NET project and your set.

Installer conditionally picking up files

I'm building a Wix installer and I need two separate versions of said installer. One that picks up the latest development build of the project and one that picks up the latest release build. Currently my fragment looks like this:
<Property Id="Program.ReleaseBuild" Value="0" />
<?define ReleaseBuild = [Program.ReleaseBuild]?>
<Fragment>
<ComponentGroup Id="ProductComponents" Directory="InstallFolder">
<Component Id="TheExe" Guid="GUID_GOES_HERE">
<?if $(var.ReleaseBuild) = 1?>
<File Id="ProjectExe" Source="(Rel Project Path)/program.exe" />
<?else?>
<File Id="ProjectExe" Source="(Dev Project Path)/program.exe" />
<?endif?>
</Component>
</ComponentGroup>
</Fragment>
And I have a transform on the msi that transforms the file after build. But the problem is that the file is picked up on compile time not install time, so both version of the installer end up having the same file contained in them. Any idea how I can conditionally grab a dev file or a rel file in the same wix project?
If you want to create installation packages based on build quality (debug versus release), you can use two product configuration and select the source based on it. This way, you can run msbuild twice, one for each configuration. I don't understand the purpose of the transform you mentioned.
So here are steps you could take to accomplish this:
Create an empty solution.
Add your wixproj to it.
Add your csproj to it.
Add a reference of the csproj to the wixproj.
Modify your File[Source] to use the project reference, this way:
<File Source="$(var.MyProject.TargetPath)" Id="ProjectExe" />
The $(var.MyProject.TargetPath) will automatically get the exe from the correct path.
Create a batch file to run the msbuild twice, one for each configuration, with the following commands:
C:\> msbuild mySolution.sln /p:Configuration=Debug
C:\> msbuild mySolution.sln /p:Configuration=Release
The result will be two installation packages, one for each configuration.