0

Following the Microsoft tutorial on NuGet .NET Framework here. I AM using VS 2019.

Everything goes fine until I get to NuGet pack. I get the following error:

'C:\Users\erics\source\repos\AppLogger.vs\AppLogger\v16\Server\sqlite3\db.lock' because it is being used by another process.

The .vs folder is created automatically in all my projects. If I close VS and delete the folder it is recreated. If I close the solution and then try pack again I get:

WARNING: NU5100: The assembly 'AppLogger\bin\Debug\AppLogger.dll' is not inside the 'lib' folder and hence it won't be added as a reference when the package is installed into a project. Move it into the 'lib' folder if it needs to be referenced.

WARNING: NU5100: The assembly 'AppLogger\bin\Release\AppLogger.dll' is not inside the 'lib' folder and hence it won't be added as a reference when the package is installed into a project. Move it into the 'lib' folder if it needs to be referenced.

WARNING: NU5100: The assembly 'AppLogger\obj\Debug\AppLogger.dll' is not inside the 'lib' folder and hence it won't be added as a reference when the package is installed into a project. Move it into the 'lib' folder if it needs to be referenced.

WARNING: NU5100: The assembly 'AppLogger\obj\Release\AppLogger.dll' is not inside the 'lib' folder and hence it won't be added as a reference when the package is installed into a project. Move it into the 'lib' folder if it needs to be referenced.

Improve this question
5
  • Hi Eric, any update for this issue? Please check if this issue is resolved or not, if it persists please feel free to contact us. Commented Jun 17, 2019 at 10:05
  • @Lance Li-MSFT Please see zivkan's answer below. Commented Jun 17, 2019 at 14:41
  • Hi, I've checked it, since it solved your issue, why not consider marking it as accepted answer. Also, you can add your answer below since it seems you've not stuck at it any more:) Commented Jun 18, 2019 at 1:34
  • @Lance Li-MSFT I will I suppose. Not to me a smart a** here. This is an honest question. Wouldn't it make more sense to pressure MSFT to get their actual docs up to date rather than leave the docs outdated and pressure Stack users to update their Stack questions? Actually, I think I will leave this unanswered until MSFT gets their docs updated. Please let me know when that is accomplished and I will point to the updated docs/tutorials and close the question. Commented Jun 18, 2019 at 12:47
  • Hi friend, check this link, always we can seed the feedback about nuget documents there. I suggest you can open new thread there and let them know. Commented Jun 20, 2019 at 10:23

3 Answers 3

Reset to default
1

The NuGet docs were written before SDK style projects existed (before .NET Core was created), and mostly has not been updated since. Therefore the tutorials are very much out of date.

My 30 second tutorial for creating NuGet packages:

Create a "Class library (.NET Core)" project, even if you want to target the .NET Framework. You can also do this from the command line using dotnet new classlib. If you want to target the .NET Framework, right click the project in Solution Explorer, and select "edit project file" (or edit the csproj in your favourite text editor) and change <TargetFramework>netcoreapp2.2</TargetFramework> to <TargetFramework>net472</TargetFramework>, or whatever .NET Framework version you want (remove the dots so 4.7.2 is 472, 4.7 is 47, not 470). Finally, right click the project in Solution Explorer and select Pack, or run dotnet pack from the command line.

Packing SDK style projects (or traditional projects with the MSBuild pack targets) is much improved over using nuget.exe pack and nuspec files, so I strongly suggest using that instead. We (NuGet team) really need to find the time to update the docs.

Improve this answer
Sign up to request clarification or add additional context in comments.

5 Comments

"We (NuGet team) really need to find the time to update the docs." - Thank you! Thank you! Thank you! I cannot tell you how good that is to hear. I will try your 30 second tutorial and see how it goes.
"Packing SDK style projects (or traditional projects with the MSBuild pack targets) is much improved over using nuget.exe pack and nuspec files, so I strongly suggest using that instead." Can you please point me toward a tutorial that you think makes sense?
sorry, I don't know any. But the msbuild pack targets support more scenarios and the aim is that customers never need to create a nuspec file, at least for 99% of packages. using nuget.exe pack there are only limited support for various scenarios, meaning it's more common to need to create a nuspec file and that causes package compatibility issues when the package don't conform to nuget conventions.
Looks like all I need to do is build by class project, go to the solution I want to use that class project in, create a reference to the .dll that the class project build created and then use it. This seems to work OK in a local dev environment.
you shouldn't reference the dll directly. Either use a project reference if it's in the same solution, or use a package reference if it's in a different solution. If you reference the dll directly, then you will need to build your projects in a specific order, that MSBuild won't know about and therefore can't do for you automatically.
0

I've checked the tutorial and reproduced same issue.

When VS is running with current project AppLogger opened, the .vs folder is used by it. (Create a new solution, and navigate to the SolutionDir, you can find the .vs is occupied by VS since we will fail to delete it when VS is running)

According to this error message, when using nuget pack command, it will also try to read some data from .vs folder. But the .vs has been occupied by VS and the nuget.exe can't access it. So the error occurs.

I would think it needs some additional note to the document like:

Note: To run the nuget pack xxx.nuspec successfully, you should close VS instance before it.

If I close the solution and then try pack again I get the warnings:

The warnings indicate that the assemblies you want to package should be copied to lib folder so that the project who loads this package can get the assembly. A simple way to reslove this error messgae is: Create a lib folder in the project folder and copy the xxx.dll into it. Then use the nuget pack command again.

Then the xxx.nupkg we created contains the assembly. Create a new .net fx project, load the xxx.nupkg, now we can reference the AppLogger.dll correctly.

(Also, the warning would still displays:WARNING: The assembly 'lib\AppLoggerSampleMyTest.dll' is placed directly under 'lib' folder. It is recommended that assemblies be placed inside a framework-specific folder. Move it into a framework-specific folder.) But it's just a warning, which suggests to help make a better nuget package structure.

And according to your last comment, you're working in local dev development. Then you don't have to create nuget packages for this situation. I think class library project template itself is enough for your situation.

(If they are in same solution, right-click project=>add=>reference, if not in same solution, you can right-click solution=>add existing project to include the class library project)

Improve this answer

Comments

0

I ran into this issue on internal project and we were already using SDK style project file.

The solution was to remove remaining project.nuspec file, references to that from the project.csproj and also the <NuspecProperties>... -tags from csproj.

Improve this answer

Comments

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.