I'm trying to find the Nant syntax for including a COM reference.
The current Nant script with the normal dll reference looks like ..
<references>
<include name="${external-lib}/System.Interop.AppName.dll" />
The COM reference in the .csproj file looks like this ...
<COMReference Include="System.Interop.AppName">
<Guid>{00020813-0000-0000-C000-000000000046}</Guid>
<VersionMajor>1</VersionMajor>
<VersionMinor>7</VersionMinor>
<Lcid>0</Lcid>
<WrapperTool>primary</WrapperTool>
<Isolated>False</Isolated>
</COMReference>
What syntax should I use in Nant to swap to the COM reference to do the build ?
Use tlbimp (nant task) and reference the generated assembly instead.
Related
I'm trying to build a multi-project solution in Azure DevOps for deployment to Azure. This solution builds fine on my local machine, but I get the following build error in Azure.
##[error]TCGTools.net\Controllers\SettingsController.cs(8,7): Error CS0246: The type or namespace name 'TCGSniperCore' could not be found (are you missing a using directive or an assembly reference?)
TCGSniperCore is a .netcore library in my solution. The MVC project references this library.
After skimming the full log file, I found that the solution is building the .netcore library in release mode, but then looks for the .dll in the debug folder.
Console output when building the library:
CopyFilesToOutputDirectory:
Copying file from "obj\Release\netcoreapp2.2\TCGSniperCore.dll" to
"bin\Release\netcoreapp2.2\TCGSniperCore.dll".
TCGSniperCore ->
D:\a\1\s\tcgsnipercore\bin\Release\netcoreapp2.2\TCGSniperCore.dll
Copying file from "obj\Release\netcoreapp2.2\TCGSniperCore.pdb" to
"bin\Release\netco
Console output when building the MVC project:
C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\15.0\Bin\Microsoft.Common.CurrentVersion.targets(2110,5): warning MSB3245: Could not resolve this reference. Could not locate the assembly "TCGSniperCore". Check to make sure the assembly exists on disk. If this reference is required by your code, you may get compilation errors. [D:\a\1\s\TCGTools.net\TCGTools.net.csproj]
For SearchPath "{HintPathFromItem}".
Considered "..\tcgsnipercore\bin\Debug\netcoreapp2.2\TCGSniperCore.dll", but it didn't exist.
For SearchPath "{RawFileName}".
Considered treating "TCGSniperCore" as a file name, but it didn't exist.
I have tried the following:
Ensuring both projects target .netcore2.2
Setting the Agent pool to Hosted VS2017 in Azure DevOps
Setting the BuildConfiguration variable to release
Reproducing on my local machine. I cannot. The solution builds fine.
Why is it looking for the assembly in /debug and not /release?
I found that it looks for the .dll based on the file path specified in the .csproj file. Edit the file (I used VS Code) and add/modify the hint path with $(configuration).
Before:
<ItemGroup>
<Reference Include="TCGSniperCore">
<HintPath>..\tcgsnipercore\bin\Debug\netcoreapp2.2\TCGSniperCore.dll</HintPath>
</Reference>
</ItemGroup>
After:
<ItemGroup>
<Reference Include="TCGSniperCore">
<HintPath>..\tcgsnipercore\bin\$(configuration)\netcoreapp2.2\TCGSniperCore.dll</HintPath>
</Reference>
</ItemGroup>
Thanks #D.J.
NuGet packages such as CodeAssassin.ConfigTransform tranform web.*.config or app.*.config to web.*.config.transformed or app.*.config.transformed upon a VS build.
However, what if you have config files of form {arbitrary-name}.config ?
For example, MyAssembly.dll.config and its transform rulesets MyAssembly.dll.debug.config & MyAssembly.dll.release.config
CodeAssassin.ConfigTransform does not appear to work for these file patterns.
If you look at the target source code it looks quite simple to modify it to allow any .config file to be transformed. Actually I think that transforming any XML file should be possible.
I will fork that repository tomorrow for and experiment with this.
Disclaimer: In this example I modified CodeAssassin.ConfigTransform.targets directly. But you should create a separate .targets file and reference that in your .csproj.
Add a ConnectionString.config (as an example) and then add the transforms.
Add this to the .targets file (your config name just has to match the regex expression - (?i)^ConnectionString\. in this case):
<Target Name="TransformAllConnectionStringConfigTransformFiles"
Condition="'$(WebProjectOutputDir)'!=''"
BeforeTargets="Compile">
<ItemGroup>
<ConnectionStringConfigTransformFile Include="#(None);#(Content)" Condition="'$([System.Text.RegularExpressions.Regex]::IsMatch(%(Filename),"(?i)^ConnectionString\."))' == true and '%(Extension)'=='.config'" />
</ItemGroup>
<TransformXml Source="ConnectionString.config" Destination="%(ConnectionStringConfigTransformFile.Identity).transformed" Transform="#(ConnectionStringConfigTransformFile)"
Condition="'#(ConnectionStringConfigTransformFile)'!=''" />
<CreateItem Include="%(ConnectionStringConfigTransformFile.Identity).transformed"
AdditionalMetadata="CopyToOutputDirectory=Always">
<Output TaskParameter="Include" ItemName="Content"/>
</CreateItem>
</Target>
Build, and your .transformed files are created.
I'm going to bang out a couple of questions here...first, with NuGet is it possible to create a package from a few DLLs? There is no visual studio project, just the command line and a couple of pre-compiled DLL files.
Second, assuming that is possible, why do I continuously get the "Assembly outside of the lib folder" warning? I've tried everything I can think of to get associated assemblies to add themselves as references inside of the NuGet package.
My file structure looks like this
Root
- File1.dll
- lib
- File2.dll
- File3.dll
When I tell NuGet to pack it using a .nuspec like this
<?xml version="1.0"?>
<package >
<metadata>
<id>File1.dll</id>
<version>1.0.0</version>
<authors>thisguy</authors>
<owners>thisguysmom</owners>
<requireLicenseAcceptance>false</requireLicenseAcceptance>
<description>This is some library</description>
<releaseNotes>Porting to NuGet</releaseNotes>
<copyright>Copyright 2012</copyright>
<references>
<reference file="File2.dll" />
<reference file="File3.dll" />
</references>
</metadata>
</package>
I receive that warning. From what I'm reading, I shouldn't even have to define the references node in any of my projects, as the lib folder items should automatically be added as references?
Does anyone out there understand this NuGet mess?
I just ran into this problem. Nuget is expecting a structure that looks like:
root
- lib
- net40
- File1.dll
- File2.dll
- File3.dll
net40 or net20 or net45 as appropriate to your .net version.
run
nuget pack yourlibrary.nuspec
to package it up.
That will pack up the dir wholesale and put it in the nupkg. The error messages will disappear at that point.
Any dll that you want referenced should be under the lib folder. The warning is because file1.dll is outside lib and will be ignored during package installation. (Other special folder are "content" and "tools")
I'd used this structure :
Root
- lib
- File1.dll
- File2.dll
- File3.dll
See : http://docs.nuget.org/docs/creating-packages/creating-and-publishing-a-package#Package_Conventions for additional details.
With the version of NuGet that is current as of this post (and I assume later versions as well), you can use the .csproj file, in tandem with the .nuspec file to create the package. What we did was make a .nuspec file (using nuget spec and then customizing it) and include it in the project.
With the customized .nuspec file, we used the command:
nuget pack sample.csproj -IncludeReferencedProjects
At that point it built the .nupkg and did not emit issues. The .nupkg file showed up in the normal output folder (in my default case, bin\debug).
You may add references to another dll by adding below inside tag in nuspec file
<package>
<metadata>
...
</metadata>
<files>
<file src="..\ReferencedFolder\*.*" target="lib\net40\" />
</files>
</package>
Alexandre is referring to the "lib" folder that gets created when you create a NuGet package. You can open the .nupkg just like you would any zip file. In there, you will see a lib\netXX folder where XX is the version of the .NET framework you're targeting. So when you're packing your NuGet file, make sure File1.dll is inside the lib folder.
I used Prof Von Lemongargle' solution, and for me was a great solution.
Important:
Include spec file (with right-click-> Include in project) in the project
Give to spec file THE SAME FILENAME of your project (myproject.csproj, myproject.nuspec)
This work perfectly in Visual Studio 2012.
They get into the "lib" folder by being included in your bin\debug or bin\release folder in .NET. So you need to get the project compile to copy local on the external DLLs so it includes them in the bin folder on compile.
If dependencies or libraries have been changed, old files affect the packaging operation.
Remove obj and bin folders from project.
Run dotnet restore
Run nuget pack yournuspecfile.nuspec -properties Configuration=Release -IncludeReferencedProjects or your command whatever.
I'm trying to create my first NuGet package. I don't know why my install.ps1 script does not get called. This is directory structure
--Package
|
- MyPackage.nuspec
- tools
|
- Install.ps1
- some_xml_file
I build package using this command line
nuget.exe pack MyPackage.nuspec
When I Install-Package from VS Package Manager Console install.ps1 does not get called.
I thought that maybe I had some errors in script and that's the reason so I commented out everything but
param($installPath, $toolsPath, $package, $project)
"ECHO"
But I don't see ECHO appearing in Package Manager Console. What can be wrong?
Install.ps will only be invoked if there is something in the \lib and/or \content folder, not for a "tools only" package, though. See here:
The package must have files in the content or lib folder for Install.ps1 to run. Just having something in the tools folder will not kick this off.
Use the Init.ps1 instead (however, this will be executed every time the solution is opened).
Install.ps1 (and Uninstall.ps1) are no longer called in v3, but you can use Init.ps1. See here:
Powershell script support was modified to no longer execute install
and uninstall scripts, but init scripts are still executed. Some of
the reasoning for this is the inability to determine which package
scripts need to be run when not all packages are directly referenced
by a project.
An alternative to the install script can sometimes be a package targets file. This targets file is automatically weaved into the project file (csproj, ...) and gets called with a build.
To allow Nuget to find this targets file and to weave it in, these two things are mandatory:
the name of the targets file must be <package-name>.targets
it must be saved in the folder build at the top level of the package
If you like to copy something to the output folder (e.g. some additional binaries, like native DLLs) you can put these binaries into the package under folder binaries and use this fragment in the targets file for the copying:
<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<Target Name="CopyBinaries" BeforeTargets="BeforeBuild">
<CreateItem Include="$(MSBuildThisFileDirectory)..\binaries\**\*.*">
<Output TaskParameter="Include" ItemName="PackageBinaries" />
</CreateItem>
<Copy SourceFiles="#(PackageBinaries)"
DestinationFolder="$(OutputPath)\%(RecursiveDir)"
SkipUnchangedFiles="true"
OverwriteReadOnlyFiles="true"
/>
</Target>
</Project>
In TeamCity, i need to state exact locations of assemblies that contain NUnit tests to be executed.
Is there an option to state a .SLN file so it will look up these test projects dynamically?
You can use wildcard expressions in the Run tests from box:
Source\\**\bin\\**\*Tests.dll
The above would run tests from any assembly under any bin folder under the Source folder which contains 'Tests' at the end of the assembly name.
Depending on whether you're using MSBuild or NAnt, you can add an entry to your build script like this:
<ItemGroup>
<TestAssemblies Include="tests\\test*.dll"/>
<TestAssemblies Include="tests.lib\\test*.dll"/>
</ItemGroup>
<Target Name="runTests">
<Exec Command="$(teamcity_dotnet_nunitlauncher) v2.0 x86 NUnit-2.5.0 %(TestAssemblies)" />
</Target>
In the example above, the two TestAssemblies lines point to your assemblies.
You can read more about this here: http://blogs.jetbrains.com/teamcity/2008/09/24/using-teamcity-nunit-launcher/