create an FSharp fsx script, type this:
#r "nuget: FSharp.Data"
get
Error FS3217 ...: error NU1301: Unable to load the service index for source https://pkgs.dev.azure.com/.../index.json. F# Miscellaneous Files ...\Script.fsx 1 Active
I suspect this is because i have a custom Nuget source defined in addition to nuget.org, is there a way I can force the script to just look in a nuget.org?
I find the nuget client configuration at best confusing.
I'm using visual studio 2022
I fixed it by disabling the other sources
Tools->Manage Packages for solution-> package source setting icon
disable the ones you don't want
RESTART visual studio
then it will work
it would be nice if you could specify the package source in the script, i find nuget config a bit of a black art, and I'd rather control explicitly in the script that have to change config (which i will inevitably change back and forget)
Related
I changed the project type I am packaging from .net framework v4.6 to .net standard 2.0, now the build definition is failing in Nuget packager step and I am getting this error message.
[error]The default XML namespace of the project must be the MSBuild
XML namespace. If the project is authored in the MSBuild 2003 format,
please add xmlns="http://schemas.microsoft.com/developer/msbuild/2003"
to the element. If the project has been authored in the old
1.0 or 1.2 format, please convert it to MSBuild 2003 format.
After researching about this error I understand that the NuGet packer step doesn't work on SDK-based csproj formats.
What is the best alternative available? I found the same issue here, but I can not find the command pack within the available commands.
While the pack command does not appear in the dropdown, you can enter it manually into the field.
This is how I resolved this issue:
1- Add package metadata to .csproj file.
2- Go to project properties -> package and check "Generate NuGet package on build".
3- In Build definition add the following tasks:
a- NuGet Restore:
Set path to solution.
Select Feeds in my NuGet.config as Feeds to use.
Set path to Nuget.config (Usually project root "src\nuget.config").
b- Visual Studio Build:
Set path to solution.
Platform: something like $(BuildPlatform).
Configuration: something like $(BuildConfiguration).
c- Copy and Publish Build Artifacts:
In contents enter *.nupkg.
Set Copy Root, Artifact name, and Artifact type.
I have F# project which I want to build with command line (to use that later in FAKE config).
The problem is that MSBuild fails to resolve assembly dependencies when I use it on the project file directly. While it goes fine when I use solution file with this single project included.
I really have run out of ideas. The solution file seems to not contain any critical information.
Another weird thing is that VSCode also fails to resolve one of those assemblies. I hope that when I fix MSBuild config I may be will able to see what's wrong with VSCode.
Command line:
"C:\Program Files (x86)\MSBuild\14.0\Bin\msbuild.exe" FSharpWeb1\FSharpWeb1.fsproj /t:rebuild
Error message:
C:\work\MNP\testMSBuild1\FSharpWebApi\FSharpWeb1\FSharpWeb1.fsproj(173,5): error MSB4062: The "MSBuild.ExtensionPack.FileSystem.File" task could not be loaded from the assembly C:\work\MNP\testMSBuild1\FSharpWebApi\FSharpWeb1\*Undefined*\packages\MSBuild.Extension.Pack.1.3.0\tools\net40\MSBuild.ExtensionPack.dll. Could not load file or assembly 'file:///C:\work\MNP\testMSBuild1\FSharpWebApi\FSharpWeb1\*Undefined*\packages\MSBuild.Extension.Pack.1.3.0\tools\net40\MSBuild.ExtensionPack.dll' or one of its dependencies. The filename, directory name, or volume label syntax is incorrect. Confirm that the <UsingTask> declaration is correct, that the assembly and all its dependencies are available, and that the task contains a public class that implements Microsoft.Build.Framework.ITask.Done Building Project "C:\work\MNP\testMSBuild1\FSharpWebApi\FSharpWeb1\FSharpWeb1.fsproj" (rebuild target(s)) -- FAILED.
I've pushed the minimal demo to github: https://github.com/alehro/testMSBuild.git
It's actually easy to reproduce independently. In VS 2015 Community edition create new project from F# Web Template named "Web Api 2.2" and then try to build it with MSBuild.
Another disturbing thing is that the minimal demo produces different errors from those I've seen yesterday. Also vscode complains on different items. If yesterday it could not resolve a couple of calls, now it complains on all of:
open System.Net.Http
open System.Web
open System.Web.Http
open System.Web.Routing
telling that neither of them is defined.
Reformatting my comments to a response now that it's verified it works:
Your FSharpWeb1.fsproj references MSBuild.ExtensionPack.FileSystem.File task from MSBuild.Extension.Pack, but the path specified in the <UsingTask> tag contains $(SolutionDir) property which is not defined when you run MSBuild outside of Visual Studio.
The error message you're getting shows that in the highlighted part of the path:
The "MSBuild.ExtensionPack.FileSystem.File" task could not be loaded from the assembly C:\work\MNP\testMSBuild1\FSharpWebApi\FSharpWeb1\*Undefined*\packages\MSBuild.Extension.Pack.1.3.0\tools\net40\MSBuild.ExtensionPack.dll.
This can be remedied by conditionally setting the relative path when the property is not set by VS:
<SolutionDir Condition="$(SolutionDir) == '' Or $(SolutionDir) == '*Undefined*'">..\</SolutionDir>
(original response for this solution: https://stackoverflow.com/a/33782131/1659828)
One more thing I mentioned in the comments is that this solution assumes you already have the necessary dependencies downloaded in the packages folder. Visual Studio does that automatically by restoring NuGet packages before build, but when you build in another context, you have to make sure the packages are restored, otherwise the build will keep failing.
I'm trying to create a nuget package for the localization of another package, and I'm following the satellite package approach.
I'm pretty sure to have followed these rules strictly, and the naming conventions as well, but as I download the satellite package from my nuget repo server, it's not adding the expected /it/ folder under the /lib/ folder of the main package.
The main files structure is the following
/lib/net45/myfile.dll
and the satellite package has
/lib/net45/it/myfile.resources.dll
I tried everything, and I double check my packages configurations with the AspNet.Mvc.5.1.1 package and its satellites. They're the same...
I'm wondering if the problem could be on the NuGet server (but sounds weird to me)?
The server version is v2.8.50126.400
UPDATE
So it really seems to be the Server, as if I use a local path (C:...) as repo source, the packages act as expected.
Anyway I've just used the NuGet.Server package to create the server, there's some particular configuration I missed?
The problem was the NuGet.Server .
There's a field missing during the serialization of the feed, the Language, that's why the official packages are working: on the official server the Language field IS serialized, that allow the NuGet client to move the resource assembly to the right folder under the main package's lib folder.
But on a private repository built with the NuGet.Server package this field is just missing.
I've applied a pull request on Codeplex, for the ones who have the same issue.
https://nuget.codeplex.com/SourceControl/network/forks/tanathos/nuget/contribution/6524
I am moving our source code from Vault to TFS, not bothering with the migration or anything, just pulling a get latest in vault and adding it to TFS.
The solution has got several projects, and each one has at least one NuGet package. I am trying to get Package Restore working again. It worked in Vault (but not the way it was supposed to). I was under a bit of a deadline, and it did not work at first, so I added a Pre-Build event to run nuget.exe against the packages.config for each project.
TFS build service complains about that, so I am trying to get it working "right".
I have set the option in Visual Studio Tools menu.
I have installed NuGetEnablePackageRestore and run the fix.
I have verified that the packages directory is is source control, but is empty.
I have verified that the project files each include the following:
<RestorePackages>true</RestorePackages>
<Import Project="$(SolutionDir)\.nuget\nuget.targets" />
Building with Diagnostic level verbosity reveals that each project evaluates those properties, but the RestoreCommand in nuget.targets is never executed.
Any thoughts?
I have attempted to implement the solutions from these links:
nuget - package restore not working
NuGet Package Restore Not Working - I did post a question/comment on there asking for clarification...
http://nuget.codeplex.com/workitem/1879
Edit
Additionally, I have found that the RestoreCommand property is being evaluated during build. Diagnostic Verbosity shows:
RestoreCommand = (set EnableNuGetPackageRestore=true) && "C:\Source\Kiersted Direct And Related\Direct\Kiersted\.nuget\nuget.exe" install "packages.config" -source "#(PackageSource)" -o "C:\Source\Kiersted Direct And Related\Direct\Kiersted\packages"
I figured it out, and I found the answer here: MSBuild not running BuildDependsOn tasks from an imported project
The problem (after looking through the Diagnostic verbosity build output) was that the BuildDependsOn setting was getting un-set. My project files each had the import statement
<Import Project="$(SolutionDir)\.nuget\nuget.targets" />
but that statement was at the beginning of the XML tree. Apparently the import for Microsoft.CSharp.targets can interfere with that import and thus the BuildDependsOn.
My solution was to move the nuget.targets import to below the Microsoft.CSharp.targets import. Now everything builds beautifully.
This answer needs to be considered with the others. In my case, Visual Studio decided not to add the packages.config automatically into Source Control. Hence the file did not make it's way through to the build server for consideration during Nuget restore.
Problem description:
Consider the following command line call (called for Delphi 2009 compiler):
dcc32.exe --no-config --peflags:1 Project.dpr
Will this call use the Project.dproj or Project.dof configuration files ?
If yes, will the command line options take precedence over the configuration file(s) ?
If not, where the build configuration will be taken from if the dcc32.cfg file is not loaded in this case ?
Problem background:
I know that MSBuild should be used since Delphi 2007 but in fact, it's the reason why I'm asking. I found that InnoSetup uses this batch file for building its projects and I have serious problems to link the JEDI JVCL library to it (it's a pure nightmare). So I'd like to configure the project settings to use MSBuild, but I'm not sure what build settings are used in the above command line call.
--no-config means that dcc32.cfg is not loaded, neither from the compiler executable directory, nor from the project directory.
The rules for applying options specified in .dproj and .dof files are not affected. Those options are applied and any command line options take precedence.