We Keep Coding

Published folder name and manifest not getting updated

I have a C# Windows Forms Application. I published using the publish profiles to the folder in my local, then copy it to the server. The business will run the setup and install it.
VStudio Version - VisualStudio -2017
.NET Framework - 4.8
I have changed the assembly version manually using assemblyInfo.cs file and my current version are 2.0.0.7.
But I'm facing the below issues.
When I publish the folder, the folder inside the Application files are always getting the older version name (ProjectName_2_0_0_5).
Thus making the manifest and application manifest to point to the Older version files. So the Manifest file is not getting updated.
To rectify this error for the time being, manually I have updated the folder name to the current version and application manifest file to point to the current folder location.
But still, I'm facing an issue in the deployment. But I know changing manually is not the correct way to do it. I'm missing something. I don't know how to do that. Please guide me and try to fix it permanently.

I think that setting is not available when doing a publish by right-clicking the project,
But if you publish your project through Project => MyProject Properties menu, you can set the version of your package and click Publish Now.
The gist of all this is,
Normally, you don't change the version numbers that often, but the revision number keeps incrementing, and VS publish has support for this. See the checkbox "Automatically increment revision with each publish".
This is your package version, not your assembly version, and they don't have to match, since you can have multiple assemblies under a single setup package and each may have different versions.
It is the package version number which holds together all the compatible versions of your (or any external) assemblies.
The package version number is what your customers know when they set-up.
Hope this helps.

Thanks Oguz Ozgul for giving a lead to fix this issue.
Answer to Question 1:
- As stated above, i have done the changes on the Solution Properties to update the package.
After i have done this, when deploying i got DeploymentDownloadException. I fixed it by updating the application manifest xml
- I have changed the deployment install = false alone and then removed the sub tags inside deployment tag in the application manifest xml. Then it worked fine.

Issue finding and using lib folder in Nuget package C# project

I am working on creating a sample Nuget package to test out the process of creating an internal Nuget package for use in another project of mine. My end goal is to create a simple Nuget package, which can be installed onto another simple C# project, and tested out.
I have been following the Microsoft tutorial to create & publish a package using VS:
https://learn.microsoft.com/en-us/nuget/quickstart/create-and-publish-a-package-using-visual-studio-net-framework
I successfully created & published my package on nuget.org, called MyNugetPackage, and attempted to install it onto my other C# project called TestingMyNugetPackage. I received an error in the NuGet package console stating:
Package does not support any target framework
This error makes sense, because I had read about supporting multiple .NET versions and specifying the version under the lib folder, and I definitely did not do that when creating my package:
https://learn.microsoft.com/en-us/nuget/create-packages/supporting-multiple-target-frameworks
This idea of lib folder makes sense to me and I think I understand how to add my target .NET version to it. However, I cannot find this folder anywhere! It's not anywhere in the C# project directory. I assume I may need to create it on my own, but I'm not sure where to put it.
Many tutorials and SO questions I have read about this topic talk about how to use the lib folder, but no one ever says where it is. I'm a complete beginner to this and I know I am missing something obvious here, but I'm not sure what it is.
Edit: I did try to change my .nupkg file to a .zip file and extracting the contents in attempt to view the lib folder. This did work in extracting the contents, but I did not see any lib folder after expanding entire project tree and searching for lib.
Here is a quick layout of my C# solution tree:
Solution titled MyNugetPackage with a MyNugetPackage.sln file, a MyNugetPackage.csproj file, and a simple class Logger.cs that just has a public void Print(string text) { Console.WriteLine(text); } method:
MyNugetPackage
MyNugetPackage.csproj.1.0.0.nupkg
MyNugetPackage.nuspec
MyNugetPackage.sln
MyNugetPackage (folder)
bin (folder)
Debug (folder) -> .dll, .pdb
Release (folder) -> .dll, .pdb
obj (folder)
Debug (folder)
Release (folder)
Properties (folder)
AssemblyInfo.cs
Logger.cs
MyNugetPackage.csproj
Could someone direct me where I need to place my lib folder, so that I can add my supported .NET 4.7 framework reference, and successfully install my package?

A NuGet package (.nupkg) is just a zip file. If you are trying to view the contents of this file, open it like a zip file (using 7zip or something). Alternatively change the extension to zip. In the package you will find the "lib" folder as well as the .nuspec, and package folder (among other contents). But this is the resulting package that is built when you Pack your project, changes here would have no affect on your code.
If you're just trying to target one or more frameworks. In VS, edit your project file (.csproj). This file is an XML with a PropertyGroup that contains either a "TargetFramework" OR a "TargetFrameworks" element. To target a single framework add a TargetFramework element, to target multiple use the TragetFrameworks instead.
To target a single .Net framework:
<PropertyGroup>
<TargetFramework>net472</TargetFramework>
</PropertyGroup>
Alternatively, you can target multiple frameworks.
<PropertyGroup>
<TargetFrameworks>net472; netcoreapp3.0; netcoreapp2.1</TargetFrameworks>
</PropertyGroup>
This would target .Net 4.7.2, .Net Core 3.0, and .Net Core 2.1

Facing build error with System.Net.IMAP4 in Azure DevOps

I have a C# project in my local and it is working perfectly in my local machine. When I try to build the same project through Azure DevOps it gives the following build error
[error]d:\a\1\s\packages\System.Net.Imap4.0.1.0\System.Net.Imap4.sln.metaproj(0,0):
Error MSB3202: The project file
"d:\a\1\s\packages\System.Net.Imap4.0.1.0..\example\example.csproj"
was not found.
d:\a\1\s\packages\System.Net.Imap4.0.1.0\System.Net.Imap4.sln.metaproj
: error MSB3202: The project file
> "d:\a\1\s\packages\System.Net.Imap4.0.1.0..\example\example.csproj"
was not found.
[d:\a\1\s\packages\System.Net.Imap4.0.1.0\System.Net.Imap4.sln]
Project
"d:\a\1\s\packages\System.Net.Imap4.0.1.0\System.Net.Imap4.sln" (1) is
building
"d:\a\1\s\packages\System.Net.Imap4.0.1.0\System.Net.Imap4.csproj"
In the IMAP4 library, it specifically says that the following file was not found. When I added the package through Nuget Package Manager it installed perfectly but does not download the mentioned file example/example.csproj in the packages/System.Net.Imap4.0.1.0 folder.
d:\a\1\s\packages\System.Net.Imap4.0.1.0\System.Net.Imap4.sln.metaproj : error MSB3202: The project file "d:\a\1\s\packages\System.Net.Imap4.0.1.0..\example\example.csproj" was not found.
System.Net.Imap4.0.1.0 package structure
System.Net.Imap4.0.1.0/lib/net35 (inside the lib there are no files and it contains only net35 folder)
System.Net.Imap4.0.1.0/properties
What I am missing here to build the project successfully?
Note: I tried to view the hidden files also but the example.csproj file was not found.

Facing build error with System.Net.IMAP4 in Azure DevOps
This issue should comes from that nuget package. I have download that nuget package from nuget.org, then I unzip it, I found that the package did not contain the file example.csproj:
So, this issue related to the package, I am not sure if you are the Owners/Authors of that package, if yes, you need to re-create that package.
In addition, I have a long time to use/support nuget. According to my experience, this package is not correct. As we know, nuget:
An essential tool for any modern development platform is a mechanism
through which developers can create, share, and consume useful code.
Often such code is bundled into "packages" that contain compiled
code (as DLLs) along with other content needed in the projects that
consume these packages.
But that package packaged the entire project, which is not the correct way, it should only include the dll files.
You can check this document for some details.
Hope this helps.

The build error resolved with the following changes.
Navigate to this folder path /../System.Net.Imap4.0.1.0
Open the System.Net.Imap4.sln file and remove or comment the example/example.csproj line from the file.
Build the project
Build is successful

Nuget SQL Compact, deployable assemblies

The DLL files under _bin_deployableAssemblies belongs to SQL Compact....
apparently do not get installed via Nuget (neither with Microsoft.SqlServer.Compact 4.0.8854 or EntityFramework.SqlServerCompact 6.1.1). Exclude the _bin_deployableAssemblies from Git and when a co-worker cloned the project only "shadow" copies of the dll files were present. The automatic build copy process from _bin_deployableAssemblies to bin failed for him.
Don't have a history of my Nuget installations but I suspect either a package setup up this dll or I did it somehow in the solution.
Read Michael Dudley's blog about pushing SQL Compact with projects. Along with a Nuget setup that tries to address 4.0.0.1 assemblies.
Is there a reason why these dll are missing when cloning the project? Why the shadow copies then?

Is there a reason why these dll are missing when cloning the project?
Perhaps because executable files and bin directories aren't usually considered source files under version control.
Why the shadow copies then?
The "shadow" copies are presumably the items in the project file, i.e. the DLLs are identified in the project file

How to appropriately treat the assembly on the package folder when check in to the TeamFoundationServer at VisualStudio.com?

I was creating ASP.NET MVC 5 web app and put it in the Team Foundation Server source code control (visualstudio.com). There is a folder named "packages" that contains all assembly I've got thru nugget. After a while, I need to create another app, and I use TFS to get latest version of my code from TFS. But all the references to the third parties assemblies that point to the folder "packages" seems to have some problem. The icons has yellow triangle with exclamation point for each assembly. How do I fix this problem?

That's because NuGet just creates the folder with referenced packages but it doesn't add it to your source control. Why don't you just add the folder NuGet created to your solution and that way it will become a part of your project in TFS?
That way your TFS server will have all the required packages and will be able to copy the packages to your new solution or if you try to open the solution on another computer.