Develop Reference

When we create a Web Application project in Visual Studio 2019, but when we open in VS Code and use dotnet cli it gives Microsoft.targets errors

Below is the error when we run dotnet cli commands such as "dotnet build" or "dotnet run" in the terminal.
error MSB4019: The imported project was
not found. Confirm that the expression in the Import declaration "C:\Program Files\dotnet\sdk\5.0.203\Microsoft\VisualStudio\v16.0\WebApplications\Microsoft.WebApplication.targets" is correct, and that the file exists on disk.
It is something to do with VSTool path of .csproj file but not able to figure out where is the fix. Looking for your inputs. Thanks in Advance.

The $(VSToolsPath) is like: $(Tool Installation Directory) + "\Microsoft\VisualStudio\v16.0\".
And the "WebApplications\Microsoft.WebApplication.targets" file is from msbuild tool.
You should use msbuild.exe instead of dotnet.exe to do build.

NuGet pack "The DateTimeOffset specified cannot be converted into a Zip file timestamp"

When I want to pack my library as a NuGet package, I get the below error
The DateTimeOffset specified cannot be converted into a Zip file timestamp
I'm using the below command to pack my project:
dotnet msbuild /t:pack /p:Configuration=Release /p:SourceLinkCreate=true

The problem is; some DLL files have invalid dates for a zip file (like 31/12/1979).
You can overcome this issue by updating all the invalid DLL files modification date.
Here's the Powershell script that updates all the invalid DLLs.
gci -path "C:\" -rec -file *.dll | Where-Object {$_.LastWriteTime -lt (Get-Date).AddYears(-20)} | % { try { $_.LastWriteTime = '01/01/2020 00:00:00' } catch {} }
It sets all the invalid DLL dates to 01/01/2000.
Change the path parameter for your computer.
My GitHub repositories are on my C drive so I'm running this -path C:\.

Seems that in most of cases (basing on research in github issues) the problem was related to Microsoft.Extensions.* packages. In my case update to newer version of Microsoft.Extensions.* (from 3.1.0 to 3.1.4) fixed the problem. For reference :
https://github.com/dotnet/extensions/issues/2750
and mentioned in comments :
https://github.com/NuGet/Home/issues/7001

I made a console app to fix invalid dates in a drive (cross-platform). It sets the LastModificationDate to 01/01/2000. You can just run it without any arguments. It will run in all your drives. Also you can specify a directory to search in.
Source-code on GitHub:
https://github.com/ebicoglu/FileBulkDateChanger
Usage:
FileBulkDateChanger.exe
or
FileBulkDateChanger.exe C:\
For MAC/Linux,
dotnet FileBulkDateChanger.dll
Run this tool and forget about this issue :)

DinkToPdf Net Core not able to load DLL files

I am trying to generate PDFs from HTML SQL server database using DinkToPdf library.
In the startup file I have added:
var context = new CustomAssemblyLoadContext();
context.LoadUnmanagedLibrary(Path.Combine(Directory.GetCurrentDirectory(), "libwkhtmltox.dll"));
The line gives me this error on launching the web app:
DllNotFoundException: Unable to load DLL 'C:\Program Files\IIS Express\libwkhtmltox.dll' or one of its dependencies: The specified module could not be found. (Exception from HRESULT: 0x8007007E)
System.Runtime.Loader.AssemblyLoadContext.InternalLoadUnmanagedDllFromPath(string unmanagedDllPath)
DllNotFoundException: Unable to load DLL 'C:\Program Files\IIS Express\libwkhtmltox.dll' or one of its dependencies: The specified module could not be found. (Exception from HRESULT: 0x8007007E)

Just in case anyone else is having the same issue I was able to solve it by installing Microsoft Visual C++ 2015 Redistributable.

It is mentioned in library's git repo that you should download binaries and include them in your source code:
Copy native library to root folder of your project. From there .NET Core loads native library when native method is called with P/Invoke. You can find latest version of native library here. Select appropriate library for your OS and platform (64 or 32 bit).
What was breaking things was that I was going to that url and right click on each file and select save link as(chrome). This leads to a broken file being downloaded:
DON'T DO THAT
you have to open each file within github and then use that Download button.
The healthy file is much bigger than what you would get if you go the wrong way!
ridiculous but the problem may be caused by this ...

On Asp.Net Core application I use it like this to get the current directory on runtime
#if DEBUG
//windows
string filePath = $#"{Path.GetDirectoryName(Assembly.GetExecutingAssembly().Location)}\libwkhtmltox.dll";
#else
//linux
string filePath = #$"{(($#"{Path.GetDirectoryName(Assembly.GetExecutingAssembly().Location)}/libwkhtmltox.so").Replace(#"\", #"/"))}";
#endif
CustomAssemblyLoadContext context = new CustomAssemblyLoadContext();
context.LoadUnmanagedLibrary(filePath);
serviceCollection.AddSingleton(typeof(IConverter), new SynchronizedConverter(new PdfTools()));
#endregion

I found some work-arounds. They are not perfect but worth a try, and they did do help and I was able to generate PDFs from SQl Server. I put the .dll files in the following folder and it worked.
C:\Program Files\IIS Express
and the loaded the .dll files with
Path.Combine(Directory.GetCurrentDirectory(), "libwkhtmltox.dll");
The other way I went for the whole Path
context.LoadUnmanagedLibrary(Path.GetFullPath(#"C:\Users\User\source\repos\WebSolution\WebApp\libwkhtmltox.dll"));
Both of them worked. However, I urge Net Core developers to work on the GetCurrentDir very well. Or a Method to load from the Project or Solution Folder
Path.Combine(Directory.GetCurrentDirectory(), "libwkhtmltox.dll");

if you are using asp.net core on Linux then you need to install required packages by using following command
apt-get update \
&& apt-get install -y --no-install-recommends \
zlib1g \
fontconfig \
libfreetype6 \
libx11-6 \
libxext6 \
libxrender1 \
&& curl -o /usr/lib/libwkhtmltox.so \
--location \
https://github.com/rdvojmoc/DinkToPdf/raw/v1.0.8/v0.12.4/64%20bit/libwkhtmltox.so

create nuget package fails with 'Path is not of a legal form'

In a post build step we create nuget packages. For some reasons this always fails on my machine, while it works on other developers machines.
The command executed is:
nuget.exe pack "$(ProjectPath)" -Properties Configuration=$(ConfigurationName) -OutputDir "$(ProjectDir)..\Apps"
The output i get is:
Packing files from ''.
Using 'Organisation.AppName.Modules.Kcs.nuspec' for metadata.
The path is not of a legal form.
For other developers the first line contains the directory. What can be the reason it is working differently on my box? Are there options i can set to change this behavior?
Edit:
I downloaded the nuget source and found the point things start to go wrong. With a small test program i can simulate it:
using System;
using Microsoft.Build.Evaluation;
namespace CheckTarget
{
class Program
{
static void Main(string[] args)
{
if (args.Length == 0)
{
Console.WriteLine("usage: CheckTarget projectfile.csproj");
Console.WriteLine();
return;
}
string path = args[0];
var project = new Project(path);
Console.WriteLine("TargetDir = {0}", project.GetProperty("TargetDir") != null ? project.GetProperty("TargetDir").EvaluatedValue : string.Empty);
Console.WriteLine("TargetPath = {0}", project.GetProperty("TargetPath").EvaluatedValue);
Console.ReadKey();
}
}
}
On my machine the targetdir is null, on another machine the targetdir points to valid directory.

Use property Platform to -Properties parameter in nuget program
-Properties Platform=$(Platform)
where $(Platform) is one of your project platform (defined in csproj file, typically x86, 'Any CPU', ..).
ie in your case, run something like:
nuget.exe pack "$(ProjectPath)" -Properties Configuration="$(ConfigurationName)" Platform="$(Platform)" -OutputDir "$(ProjectDir)..\Apps"

Finally found the answer. This thread helped me locate the problem:
http://social.msdn.microsoft.com/Forums/en-US/msbuild/thread/d3c6e2de-1e87-49c2-b059-df074868e315/
On my machine there was an environment variable 'platform' with value 'BWS'. Deleted it and things are working!

I had the same problem basically it was an old nuget version that I carried in my source control, I deleted the .nuget folder then I uninstalled nuget from visual studio, by selecting
tools > extensions & updates,
select nuget & uninstall and then do the same process but for Installing it, just make sure you al searching in the "online" repository.

I had to update the Nuget Manager from Updates And Extensions. Restarted VS, and it worked fine.

For me the problem was that no .dll was inside the Debug folder and without the -properties Configuration=Release option nuget usually tries to find a dll in the Debug folder.
Running nuget pack manually gave me an useful error message. Running it as post build event I got the same obscure error message as you.

Using MSBuild in C#

I have some batch codes:
Path=C:\Windows\Microsoft.NET\Framework64\v4.0.30319
ECHO Trying TFS build...
msbuild D:\WORK\project\project.sln /p:Config="Debug" /p:Platform="Any CPU" /flp1:logfile=BuildLogProject.txt
That is working right. And I want to use MSBuild in my C# application.
I added Microsoft.Build.Engine reference and I'm using Engine class. I wrote some codes. But it is not working.
When I build project with Visual Studio or batch program "build succeeded" . When I build the project with my program it finds errors and warnings that are not in the project.
Engine engine = new Engine();
engine.BinPath = #"C:\Windows\Microsoft.NET\Framework64\v4.0.30319";
FileLogger logger = new FileLogger();
logger.Parameters = #"logfile=D:\WORK\project\BuildLogProject.txt";
engine.RegisterLogger(logger);
string projectPath = #"D:\WORK\project\project.sln";
try
{
bool success = engine.BuildProjectFile(projectPath);
}
catch (Exception ex)
{
System.Windows.Forms.MessageBox.Show(ex.Message);
}
finally
{
engine.UnregisterAllLoggers();
engine.UnloadAllProjects();
}

Your problem is that you trying to build .SLN file. Solution file isn't msbuild script itself.
only underlying .<XX>proj files are using msbuild format.
Actually when you run msbuild.exe someSLN.sln - msbuild autogenerates script based on your sln file and then execute it by engine. I don't know how you can generate it yourself, but you can peek into autogenerated file by using special environment variable (not working if you trying to pass it as property via command line).
Perform SET MSBuildEmitSolution = 1
and after execution msbuild.exe someSLN.sln you will find someSLN.sln.metaproj file near .sln one. This is what exactly shipped to build engine when you trying to build solution via command line and msbuild.exe