✅ [SOLVED] MSBuild Task says file does not exist
I've made a custom MSBuild task to zip up the newly created
.dll
along with relevant files for release whenever the project is built. For some reason though, it says the newly created .dll
does not exist... When the log literally shows its existence in the exact location like two line up:
Like, it just copied the file into the exact location it's complaining about
Here's the relevant snippet of the ZipTask:
And here's the part of my project's .csproj
that calls it:
Yes, I'm aware that there's no \
between the $(OutputPath)
and $(AssemblyName)
, the $(OutputPath)
property has the \
included, and you can tell in the error message that it's successfully adding a /
between the directory and file name.
Any thoughts?18 Replies
is there a particular reason you created a custom task for this?
as opposed to just calling
exec
on a zip command, I'm assuming?instead of using the already existing
ZipDirectory
I was not aware that that task existed. I suppose I could achieve this by combining that task with the
Copy
and Delete
tasks, although I do feel my approach is cleaner ¯\_(ツ)_/¯
Would that fix the issue?as clean as having to maintain another library can be ;)
and/or do you know why
File.Exists()
fails in this case?
fair enough loli would assume your target runs before the actual build
so there simply is no built dll yet
Look at the initial error message, it runs the task after the copy step
putting
AfterTargets="Build"
also fails
and if that is the case, using the ZipDirectory
task wouldn't solve anythingbtw
$fileexists
yeah msbuild does this quite differently
https://github.com/dotnet/msbuild/blob/main/src/Tasks/ZipDirectory.cs
they always fall back to a try catch
apparently
will throw it in the task rq
I take back that "apparently"
actually, that may be because I'm not running this in VS
regaredless, that sucks
I can always try passing in a hard-coded absolute path
nope, same error
will do a try/catch
won't really change anything i'd think
what even is that output dir lol
?
well it's just that it's really unusual
and there's not ever really a reason to mess with the output dir
ah
my other project has a lot of funky stuff going on w/ manipulating the build output (hence the changes), and I just copied the directory props/targets from it when I made this project
OH
I'M A FUCKING DUMBASS
:blobfacepalm:
So... fun fact
It turns out that if you don't accidently delete the file in the task before you go to copy it... It will still exist
😐
$close
If you have no further questions, please use /close to mark the forum thread as answered