I'm creating ASP.NET Web API2 in .NET Core 2.0.
I've just created my own NLog.config file. Everything work fine locally, but during VSTS build, the NLog.config file is being updated to default one.
Just thinking if it can be a overwritten during Nuget Restore? But when restoring packages locally anything happen.
Does anyone meet with something similar? Founded workaround which is changing default config name to e.g NLogProd.config, but want to achieve goal without workaround.
This issue can be caused by using the NLog.config nuget-package as <PackageReference> on .NetCore:
https://www.nuget.org/packages/NLog.Config
Microsoft decided to refactor the nuget-package-format, that caused lots of nuget-packages to stop working like the NLog.config nuget-package.
The solution is to stop using the NLog.config nuget-package, but instead use:
https://www.nuget.org/packages/NLog
https://www.nuget.org/packages/NLog.Schema
See also: https://github.com/NLog/NLog/wiki/NLog-Install
Related
I have a build pipeline configured for a Service Fabric solution on Azure DevOps like this:
Everything was fine until a few days ago when the build started failing on a particular build agent (private), with the following error (for a few projects):
C:\Program Files\dotnet\sdk\2.1.200\Sdks\Microsoft.NET.Sdk\build\Microsoft.PackageDependencyResolution.targets(327,5): Error : Assets file 'F:\Agent03\w\84\s\src\MyProject.Sam.Tiles.Domain\obj\project.assets.json' not found. Run a NuGet package restore to generate this file.
The failing task is the Build solution $(PathToSolution) one.
The weird thing is that the build fails when running on some agents but with others the build is fine.
Some details:
Use NuGet 4.x task started using NuGet v4.9.1 very recently, I think. I tried using v4.8.1 with no luck;
Most of the projects use the PackageReference format, but the .sfproj project uses the packages.config file
I tried using the dotnet restore task but there is an error when trying to restore the packages for the .sfproj project:
`Error : Unable to find the
'....\packages\Microsoft.VisualStudio.Azure.Fabric.MSBuild.1.6.7\build\Microsoft.VisualStudio.Azure.Fabric.Application.props'
file. Please restore the
'Microsoft.VisualStudio.Azure.Fabric.MSBuild' Nuget package
Any idea on what might be causing this issue?
Some of the projects use the PackageReference format but the .sfproj project uses the packages.config file.
I still don't understand why the build started failing, but I was able to find a workaround. Given that PackageReference is not yet supported in Service Fabric projects, my workaround was to use both restore tasks as follows:
My problem turned out to be a solution that didn't include all the necessary projects.
I have a master solution file that includes all my projects, and a number of smaller solution files with only some of the projects. The master solution built fine in Azure DevOps, but the partial solution failed.
I realized that the missing project.assets.json file belonged to a project that needed to be included in this failing solution.
Trevor's comment on 2/20 gave me the clue. You likely don't have the complete set of projects referenced by the solution. (ProjectReferences may go to other projects, which are not in the solution).
Here is why this crazy workaround (run dotnet.exe and nuget.exe restore tasks) worked:
dotnet restore will walk project references by default to ensure they are restored also.
--no-dependencies switch can turn that off.
nuget.exe restore has the opposite default, because we didn't want to break old users.
-recursive can turn this on.
The right solution is to make your solution contain all the projects.
-Rob Relyea
NuGet Client Team, Engineering Manager
The Restore step fails in my build definition with this error:
error NU1100: Unable to resolve 'AutoMapper (>= 6.2.2)' for '.NETCoreApp,Version=v2.0'.
This is in a .NETCoreApp 2.0 that is using AutoMapper. Restore succeeds locally in VS 2017. Locally I am using dotnet sdk 2.0.0, and nuget 4.3.1. On the VSTS (cloud) server, I am specifying the latest nuget version, 4.5.0. I have tried many other versions, including 4.3.1 with no success.
I know there is an older, similar question here, but that was never answered satisfactorily, in my opinion.
If I look at the meta data in VS, at the top of one of the Automapper files I can see this:
Assembly AutoMapper, Version=6.2.2.0, Culture=neutral, PublicKeyToken=be96cd2c38ef1005
// C:\Users\randyg.nuget\packages\automapper\6.2.2\lib\netstandard1.3\AutoMapper.dll
From this you can see it's taking the netstandard1.3 version, which is correct. I'm wondering if the nuget on the build server is looking for a netcoreApp2.0 folder, rather than the netstandard1.3 folder? Following this theory, I tried adding this to my .csproj file:
<AssetTargetFallback>$(AssetTargetFallback);netstandard1.3</AssetTargetFallback>
My theory was this would tell nuget to look for a netstandard1.3 version of automapper if it couldn't find a netcoreapp2.0 version. However, this didn't have any effect. I later read that behind the scenes this fallback is already added automatically.
If anyone has any ideas I would greatly appreciate it. I'm pulling out (what's left of) my hair on this, as this is the only package giving me trouble, and it's a critical one for my project.
On the build server I'm using .NET Core sdk 2.0.3 as well, if that matters.
This is how I solved this: since it seemed it might have to do with my target being netcoreapp2.0, I tried adding an additional 'dummy' project to my solution, with its target = netstandard1.3. In this configuration, the restore/build succeeded. I thought I would have to maintain this dummy project for this purpose, until I tried deleteing it and now the netcoreapp2.0 solution still restores fine without it. I can only assume something was corrupted in the TFS build server NPM cache (even though I had tried checking the box to disable that cache), and once I got it to succeed once, it has cleared up whatever the issue was.
Currently i am trying to build an autogenerating client on every time i release a new api.
I've got this running i can create the project and generate files from autorest.exe and everything works fine on my machine.
However when i try to replicate the same process on the buildserver i build my sln, and once i pack i get this error:
[pack] 'Microsoft.Rest.ClientRuntime' already has a dependency defined for 'Newtonsoft.Json'.
I have added this to my csproj file to pick up on the generated files, and this works fine on my local machine.
<Compile Include="Generated\*.cs" />
<Compile Include="Generated\Models\*.cs" />
I also tried including referenced projects on the build server like so
-IncludeReferencedProjects
After a couple of days im kind of stuck here, i have been having trouble finding docs on how to actually build the autorest generated client code, if anyone knows of some please share :)
Any help appreciated :)
The answer here was to update nuget on teamcity from 3.2.0 to 3.4.3 then the solution would build and run the files, i am still not sure what changed since this couldnt build, but somehow with 3.2.0 i had 2 references to newtonsoft within Microsoft.rest.clientruntime, when i updated it went away.
After many hours of searching, the answer was to run 'nuget update -self' on the failing copy of nuget.exe.
Using a powershell script to deploy a CRM Package works well, but I am running into some unexpected behavior.
The package has 1 unmanaged solution that it uploads. It works perfectly if the solution does not exist on the target CRM organization. However, if the solution does already exist on the organization and I try to deploy it again with some changes, it will not work. The changes are not uploaded and I do not get any errors.
If I change the version number in the solution (from 0.0.1 to 0.0.2, for example) then uploading it works as expected.
I would rather not change the version every time though, and since manually uploading an unmanaged solution with the same version number works perfectly I would expect the script to be able to do it as well.
I tried using the CRM Package Deployer method of importing a package to see if it would work as I expect or if it would show any error messages.
It's messages show:
Skipping solution MySolution. Version 0.0.2 of the solution is already loaded.
So it appears that if a solution with the same name and version number exists in the organization then it will be skipped entirely. This is sort of unfortunate.
It seems I'll have to implement a workaround. I see two options:
The DeployPackage script deletes the solution in the target CRM organization (if it exists) before attempting to upload.
My ExportSolution script changes the version number every time it runs.
I have an ASP.NET MVC 2 application.
Web project contains a reference to SomeProject
SomeProject contains references to ExternalAssembly1 and ExternalAssembly2.
SomeProject explicitly calls into ExternalAssembly1, but NOT ExternalAssembly2.
ExternalAssembly1 calls into ExternalAssembly2
When I perform a local build everything is cool. All DLLs are included in the bin\debug folder. The problem is that when I use the Publish Web command in Visual Studio 2010, it deploys everything except ExternalAssembly2.
It appears to ignore assemblies that aren't directly used (remember, ExternalAssembly2 is only used by ExternalAssembly1).
Is there any way I can tell Visual Studio 2010 to include ExternalAssembly2?
I can write a dummy method that calls into ExternalAssembly2. This does work, but I really don't want to have dummy code for the sole purpose of causing VS2010 to publish the DLL.
None of these answers are sufficient in my mind. This does seem to be a genuine bug. I will update this response if I ever find a non-hack solution, or Microsoft fixes the bug.
Update:
Doesn't seem promising.
https://connect.microsoft.com/VisualStudio/feedback/details/731303/publish-web-feature-not-including-all-dlls
I am having this same problem (different assemblies though). If I reference the assemblies in my web project, then they will get included in the publish output, but they should be included anyway because they are indirect dependencies:
Web Project ---> Assembly A ---> Assembly B
On build, assemblies A and B are outputed to the \bin folder. On publish, only assembly A is outputed to the publish folder.
I have tried changing the publish settings to include all files in the web project, but then I have files in my publish output that shouldn't be deployed.
This seems like a bug to me.
I had the same problem with VS2010 and a WCF Service Application.
It turns out that if your (directly or indirectly) referenced DLL's are deployed to GAC, the VS publishing feature excludes them. Once I removed the assemblies from GAC, publishing feature started working as expected.
I guess VS is assuming that if your assemblies can be located in GAC on the machine you build, they will be located in GAC on the target machine as well. At least in my case this assumption is false.
My tests show that the external assemblies get published when I have a reference on them in the web project. I do not have to write any dummy code to make it work. This seems acceptable to me.
I agree with Nicholas that this seems to be a bug in visual studio. At least it escapes me what the reason for the behavior could be.
I have created this issue as a bug on Microsoft Connect. If anyone experiencing it could vote it up https://connect.microsoft.com/VisualStudio/feedback/details/637071/publish-web-feature-not-including-all-dlls then hopefully we'll get something done about it.
If you go into the ExternalAssembly2 reference property list and change the "Copy Local" to "True" i think that might solve your issue.
I don't know if you are watching this still but I found the solution (I had the exact same issue) via this MSDN article. Under "build action" for the file choose "Content" that should include it in the list of files publish brings over.
I have created a new Connect bug here https://connect.microsoft.com/VisualStudio/feedback/details/731303/publish-web-feature-not-including-all-dlls
I've also attached a solution and detailed steps to reproduce this issue. Lets hope this time they won't close it as Can't Reproduce.
Vote for this connect issue if you experience the missing dll problem.
Copy local did the trick. I had an issue that the Newtonsoft.Json assembly get included in the deploymeny package. Copy local was set to false.
I am experiencing the same type of issue with a web project. I have a web project that references assembly A which references assembly B. It worked fine for some time but today it was broken. I did a rebuild of the solution and this time it deployed everything correctly.
I had this same problem today. I published my web project and realized that not all of the reference DLL's were there. In particular, the indirect DLL references.
It turns out that the directory in which I was publishing to was out of disk space (network share). I had just enough space to publish all the files except for few indirect reference DLL's. The sad part is that VS08 didn't throw any errors. It just published the files are usual. I cleared out some HDD space and everything worked fine.
I didn't find the HDD space issue until I tried to manually move the DLL's over.
in my case it is quite tricky.
Reference to ExternalAssembly2 is not required to Build the project but vital for run-time since we use reflection to configure Unity container.
So, I delete the reference - build the project successfully, but get run-time error.
If I preserve the reference I can Build and Run the application but I cannot Publish it with ExternalAssembly2 - get run-time exception as well.
This is happen because of internal VS2010 assemblies optimization.
So, what we can do here?
1. Put some unrequired peice of code to use any ExternalAssembly2's class.
2. escape from reflection and use static assemblies linking.
Hope this helps to smbd.
I got the same problem and this is a VS2010 bug if there's a reference link like:
Web Project --> custom project --> assembly1 -->(indirectly) assembly2.
For now I find if I reference the Assembly1 in the web project, then assembly2 is included in the bin folder.
So I had to add an additional reference link like:
Web project --> assembly1 -->(indirectly) assembly2.
Then VS can recognize assembly2 and include its dll file in publish action.