In previous versions of VS2017, we were able to use nuspec to specify platform specific dlls, e.g., Test.dll and Test.Net45.dll for Net45, and TEst.dll and Test.iOS.dll for iOS. VS2017 provides a Package tab which allows specifying versions, descriptions, etc. but there does not seem to be a way to specify platform. I do see Configuration: N/A and Platform: N/A but these are probably not relevant. How can this be done?
Incidentally, multi-targeting would not work, because Test.dll has to stay PCL (netstandard13).
We use msbuild pack in TeamCity.
Related
I want to package some tools as a nuget and am using the Microsoft.Build.NoTargets project SDK format to achieve the same.
As mentioned in the docs, NoTargets is used when the project file does not compile any assembly. However, it needs a TargetFramework property to be set.
msbuild fails with NETSDK1013 if I don't specify some TargetFramework property.
Why does msbuild mandate that TargetFramework be specified for the NoTargets SDK csproj?
Currently this is required for it to load in VS: VS checks if the project contains TargetFramework or TargetFrameworks in the xml to load sdk-based projects in the "new" project system (the thing that powers the IDE integration of the project). Otherwise it would use the legacy system that would not understand the features the SDK uses and either not load or give you a bad experience.
The MSBuild errors could be fixed in the SDK by defaulting the property but that will still fail IDE integrations.
Also note that the SDK imports other SDKs that are meant for .NET projects (language-independent over F#/C#/VB) and so you should get features like NuGet restore or packing working without much friction when a TargetFramework is set (even if it could be defaulted to whatever the SDK is basdded on in the NoTargets itself as mentioned)
I am building a netstandard2.0, with a series of sub-dependencies, including Azure.Data.Tables. I have found that Azure.Data.Tables on >=12.3.0 is not compatible with 2.2 projects, but version 12.0.0 is (or at least it doesn't crash my .Net Core 2.2 application).
Based on these premises the resolution was simple: put version 12.0.0 in the netstandard library dependencies. There's only one problem, that when I install this library using Visual Studio into my Net Core 2.2 project I get that visual studio decides to install 12.3.0.
I have checked documentation around enforcing certain versions using the allowed wildcards(https://learn.microsoft.com/en-us/nuget/concepts/package-versioning#version-ranges-and-wildcards), such as:
<PackageReference Include="Azure.Data.Tables" Version="[12.0.0]" />
Which produces this package description just before pressing "install".
But it doens't seem to work, Visual Studio simply carries on with the 12.3.0 installation.
It turns out Visual Studio was just using the nuget cache for my locally generated packages. If I either changed the version of the packaged package then the sub-dependencies would change. As well, another way of getting the precise package would be to clear nuget's cache locally: nuget locals all -clear.
I need to package up dll via that is to be used in windows 8 metro. Since there will be ARM devices as well as x86 and x64, do I need need to build a separate dll for each, or do can I just build it for "Any CPU?"
Well, you can build the dll with "Any CPU" and it should comfortably work with all the platforms, if you are still fuzzy about the bitness issues (x86 / x64), you can build seperate DLL's and package in one nuget package.
You can refer Nuget Docs for convenctions to publish the dll's for different profiles in a single package.
Cheers!
When my file set includes DLLs with one ore more dependencies to the C++ run-time DLLs I need to install the file from VCRedist.exe. This can be difficult, since each DLL is dependent on a specific version of the C++ run-time.
How do I add automatically the run-time redistributables to my installer?
How do I handle DLLs that require different versions of the C++ run-time in the WinSxS?
You need to install the latest version (highest) version required by your libraries and a policy file that redirects older versions to the new version.
You can do both with merge modules installed with Visual Studio. They're usually located in C:\Program Files\Common Files\Merge Modules. See MergeRef element and an example how to install Visual C++ redistributable with your installer. You will also need to add a policy merge module to your install.
You can simple make sure the latest vcredist is installed, it automatically includes support for older versions.
I think the easiest it to use bootstrapper to install the runtime before your installer runs. You might need to create your own package, but it is easy to use Bootstrapper Manifest Generator for this.
In the product.xml you can add an installation check to make sure it is not installed twice, for example:
<InstallChecks>
<MsiProductCheck Property="VCRedistInstalled" Product="{1F1C2DFC-2D24-3E06-BCB8-725134ADF989}"/>
</InstallChecks>
See here for other GUIDs.
Neither heat nor Votive does support the requested feature. The run-time DLLs must be added manually.
Is it possible to build Visual Studio solutions without having to fire up MonoDevelop?
Current status (Mono 2.10, 2011): xbuild is now able to build all versions of Visual Studio / MSBuild projects, including .sln files. Simply run xbuild just as you would execute msbuild on Microsoft .Net Framework. You don't need Monodevelop installed, xbuild comes with the standard Mono installation.
If your build uses custom tasks, they should still work if they don't depend on Windows executables (such as rmdir or xcopy).
When you are editing project files, use standard Windows path syntax - they will be converted by xbuild, if necessary. One important caveat to this rule is case sensitivity - don't mix different casings of the same file name. If you have a project that does this, you can enable compatibility mode by invoking MONO_IOMAP=case xbuild foo.sln (or try MONO_IOMAP=all). Mono has a page describing more advanced MSBuild project porting techniques.
Mono 2.0 answer (2008): xbuild is not yet complete (it works quite well with VS2005 .csproj files, has problems with VS2008 .csproj and does not handle .sln). Mono 2.1 plans to merge the code base of mdtool (MonoDevelop command line build engine) into it, but currently mdtool is a better choice. mdtool build -f:project.sln or man mdtool if you have MonoDevelop installed.
for now as per August 2017 we can use
msbuild
command as xbuild is depreciated.
xbuild now supports solutions and projects, both VS2005 and VS2008.
I think you are looking for xbuild:
http://www.mono-project.com/Microsoft.Build