Dotnet run/restore without internet (Offline mode) - deployment

I have a Windows server in which I installed and restored my dotnet core project successfully (at the time when I had outbound internet connection on the server). This instance of the application is running fine now.
Now Outbound internet access has been revoked as part of data center policy. I have VPN and Remote Desktop access, though. Now, I am trying to clone my working project into a separate folder and create another instance (on a different port).
But when using dotnet run on my new project folder (all content except few settings are same), I am getting this error:
$ dotnet run
C:\Program Files (x86)\dotnet\sdk\2.2.102\NuGet.targets(114,5): error :
Unable to load the service index for source https://api.nuget.org
/v3/index.json. [C:\xxxx\xxxx\xxxx.csproj]
C:\Program Files (x86)\dotnet\sdk\2.2.102\NuGet.targets(114,5): error :
A connection attempt failed because the connected party did not properly
respond after a period of time, or established connection failed because
connected host has failed to respond [C:\xxxx\xxxx\xxxx.csproj]
The build failed. Please fix the build errors and run again.
I checked C:\Users\xxxxxx\.nuget\packages and all required packages are available.
Both projects are running under the same Windows user profile.
I have looked up various Stackoverflow questions on the subject, but all of them talk about a proxy setting, which is not my use case.
How can I prevent dotnet from looking up remote nuget server as all packages are already available in the local cache.
Is building the dll locally and running on server the only option? Cant I build it on my server in offline mode?

Ok. As it usually happens, I got the solution after posting the question on SO.
Credits: https://blog.bigfont.ca/dotnet-restore-without-an-internet-connection/
Here is a brief:
dotnet nuget locals all --list
info : http-cache: C:\Users\bigfo\AppData\Local\NuGet\v3-cache
info : global-packages: C:\Users\bigfo\.nuget\packages\
info : temp: C:\Users\bigfo\AppData\Local\Temp\NuGetScratch
Then, use one of those sources during dotnet restore
dotnet restore --source C:\Users\bigfo\.nuget\packages\
dotnet build --no-restore
dotnet run --no-restore

An alternative to the solution you discovered, is to create a nuget.config file that removes all nuget sources:
<configuration>
<packageSources>
<clear />
</packageSources>
</configuration>
This way, you don't need to use special command line arguments to restore or build.

You can try to restore your solution or project with NuSave. It's meant for offline use.
Check my answer here: https://stackoverflow.com/a/41094054/2156569

Related

Visual Studio 2019 can not get nuget packages

I wonder is there a way to make VS 2019 work with nuget repositories?
Usually it works fine, but sometimes occurs the following.
I pushed a package into my nexus enterprise repository, waited a while (package is already in repo), than opened a .csproj file and entered pushed version. VS cannot load a package with error
Failed to retrieve information about '%packagename' from remote
source
'https://nexus****/repository/nuget-group/FindPackagesById()?id='%packagename'&semVerLevel=2.0.0'.
Of course, if a copy the link to browser, it opens ok. I do have access to both nexus and nuget.org, but VS cannot get any package from them - neither through .csproj nor Nuget Manager UI is VS!
Restart machine doesn't matters. dotnet restore also produces the error.
The only thing helpful is to install VS update through the VS Installer.
Today I already installed an update, so I can't do this now.
Is there any way to make this work?
You could try to use nuget.exe to register the source in your machine.
nuget.exe sources Add -Name "source" -Source {Path to the package(s) source}
Then re-start your visual studio.
I looked at Package Manager Output and saw that sometimes a message appeared. The message was someting like 'cannot connect to host because it reject or already has a connection error at xxx.xxx.xxx.xxx'. (My dirty translate from Russian)
But the point is: this IP is neither nexus host nor any intermediate host. I found that is was our old enterprise proxy (because the new one had no access to nuget.org), which is obsolete and unsupported. So, I just deleted proxy section from %APPDATA%/Roaming/Nuget/Nuget.config and at least local nexus became always available for me.

Why is Access to the path '/bin/roslyn' denied?

Long story short, I was able to build a bitbucket .NET/MVC/Angular project successfully on windows 2019 azure hosted agent, but I am unable to make it build successfully on ubuntu agent.
The reason I want to build it on ubuntu is because I noticed the build time is way faster than that of the windows agent, which makes sense considering the platforms.
I am facing this error:
Copying file from "/home/vsts/work/1/s/Bobby.ProjectA/obj/Debug/Bobby.ProjectA.pdb" to "/home/vsts/work/1/s/Bobby.ProjectA/bin/Bobby.ProjectA.pdb".
CopyRoslynCompilerFilesToOutputDirectory:
Creating directory "/bin/roslyn".
Creating directory "/bin/roslyn".
Creating directory "/bin/roslyn".
Creating directory "/bin/roslyn".
/home/vsts/work/1/s/packages/Microsoft.CodeDom.Providers.DotNetCompilerPlatform.1.0.8/build/net45/Microsoft.CodeDom.Providers.DotNetCompilerPlatform.props(17,5):
warning MSB3021: Unable to copy file "/home/vsts/work/1/s/packages/Microsoft.Net.Compilers.2.4.0/build/../tools/csc.exe" to "/bin/roslyn/csc.exe". Access to the path '/bin/roslyn' is denied. [/home/vsts/work/1/s/Bobby.ProjectA/Bobby.ProjectA.csproj]
According to this post, the issue is because the VBCSCompiler is locking the src.
So i have exhausted all of these solutions here to kill the VBCCompiler, but none of them worked.
I also can't restart the ubuntu agent during a build due to CI limitation, and killall VBCSCompiler bash script before msbuild task resulted in this error: VBCSCompiler: no process found
So now i am stumped, if VBCSCompiler process is not even running, why is Access to the path '/bin/roslyn' denied???
Ive also tried updating/installing Microsoft.CodeDom.Providers.DotNetCompilerPlatform package per this post here, but that didnt do/help anything.
This is how my build tasks looks like if it helps:

How to install and Implement the HtmlRenderer.PdfSharp in Azure Webapp (api)

Our development team implemented Pdfsharp in order to generate the pdf at website
they installed the pdfsharp package in a local environment with using this command at VisualStudio "Install-Package HtmlRenderer.PdfSharp -Version 1.5.0.5" it working fine
comes to production environment code is deployed through Azure DevOps CI/CD
when the build process creation we are implemented Nuget, NPM, and other steps.
now we added same line command in with .Net-CLI " add package HtmlRenderer.PdfSharp --version 1.5.0.5"-----> when I doing like it through the error message
Error: The process 'C:\Program Files\dotnet\dotnet.exe' failed with exit code 1
Dotnet command failed with non-zero exit code on the following projects :
I tried to install a pdfsharp package directly in webapp (API) using PowerShell
but I don't have an idea about installing the pdfshap in backend server level is it the right way or not is still ??
Please see the overview on how to use packages.
In short, you only install/add the package to the project once. This modifies the project, and you save the modified csproj into source control. Then on the CI machine, you run dotnet restore on your solution (if your solution contains only SDK style projects, nuget restore otherwise).
And for future reference, telling us that dotnet.exe returned exit code 1 is insufficient to understand the problem. dotnet.exe's output will contain additional error information about why it failed.

Assets file project.assets.json not found when running a build on Azure Devops

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

Hosting private nuget server issue

I have setup my own nuget feed and have hosted that on our dev server.
When I try to push my packages from my local machine to dev machine as below:
dotnet nuget push C:\MyProjects\Common.2.0.0.nupkg -k myapi -s https://mydev.com/AENuget/
I get the error as:
Response status code does not indicate success: 405 (Method Not Allowed).
Now I have read and tried many settings like adding
<remove name="WebDAV" /> <remove name="WebDAVModule" />
Giving permissions to my nuget packages folder, adding app pool account but still I am not able to resolve this issue.
Secondly instead of pushing if I just copy my nuget package file to the package folder being hosted in our dev server and then in visual studio I add the new server source I get the below error:
[Package Source] The V2 feed at 'http://mydev.com/AENuget/Search()?$filter=IsLatestVersion&searchTerm=''&targetFramework=''&includePrerelease=false&$skip=0&$top=26&semVerLevel=2.0.0' returned an unexpected status code '404 Not Found'.
So looks like neither the push from nuget nor the copy is working. Looks like some permission issue which I am not able to resolve.
Would appreciate if someone can provide any inputs to this.
FYI: This works fine if I host this on my local machine.
The problems you are having seem to indicate you are having issues with the NuGet.Server and the system itself. These can be problems with the firewall, hosting configuration (IIS), or a wide variety of problems.
If you are on a very small team, you might just create a shared folder on a network server (with read/write access for the team). You can add the package source to Visual Studio by following this article. The source will be the UNC path to the directory (e.g. \\servername\path\to\nuget\folder).
NuGet.Server is a package provided by Microsoft and NuGet. This is used widely so I do not believe you have a problem with the package. If you encounter a specific problem, we may be able to help.