I've been writing less, and using Codekit to compile locally.
Everything compiles to the correct destination as it should.. but
Every time I save a less file, it creates an empty CSS file in the same location on my hard disk. This happens when Codekit is closed, so it doesn't seem to be an issue with the program itself.
I have no idea what is causing this behaviour, I have no other services running.
thanks
For others that get this problem, it's usually a missing or duplicate semicolon on a property or something simple that causes this particular issue. The hard part is tracking down the specific error, so your best bet is to try a couple of different compilers and hope for an error log that tells you at least which .less file is causing the problem. Try node.js with lessc, less.app, winless or whatever else is available to you on your OS. This is a common issues, so it's worthwhile to have another "backup" compiler handy to debug.
Related
I am trying to get a C# Visual Studio 2019/MSBuild job to build on a Jenkins build server. I know that my file paths are too long, so I have enabled Long File Paths in the Group Policy Editor (and verified that it has persisted in the registry editor after a server restart).
However, now I am getting the following error "ALINK: fatal error AL1065: File name ... is too long or invalid".
A quick google search led me to this page for Alchemy Software. However I have no idea what Alchemy Software is and why it is being used in the build process and why it is failing. (Although for the last point, I'm guessing that the Alchemy Software .dll is not "Long Address Aware", which I believe is necessary for an application to take advantage of Long Paths in Windows. But since I can't locate any .dll or .exe associated with this software, I can't be certain.)
Does anyone know why my build is still failing with this error, what Alchemy Software is, and how to get it to take advantage of Long Paths in Windows?
P.S. And please, no comments about how I should restructure my file paths to be shorter. I have tried doing that but it's impractical for this application. And anyway, it keeps popping up and is becoming a whack-a-mole situation, so I'd really rather fix the root cause rather than constantly putting band-aids everywhere.
I am going to set this as an answer since, after Hans Passant's very helpful comments and subsequent research, I think it's pretty definitive that this can mostly only be worked around, not resolved. (As possible exception will be discussed at the end of this answer.)
As stated in those comments, this error originates from a linker module called al.exe that is utilized by MSBuild for certain project configurations (more on that later). This linker can be found in a couple places, but for me it was being called from C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.8 Tools.
MSBuild can handle long file paths as long as Windows is configured to do so (by enabling long paths in the Group Policy Editor or by modifying the registry directly). However this al.exe module cannot. And as far as I can tell, there's no way to force it to do so. So if your build tool chain requires this al.exe module to be used, you're kind of SOL.
For my particular situation, for a job in Jenkins that was failing because my paths were too long, I worked around this by changing the workspace of my job. So now instead of the default of something like D:\Jenkins\workspaces\[product]\Releases\[product_version], I changed it to D:\j\dd0_1c, which is an encoding that makes sense to me. This shortening of the folder path avoids any subsequent file paths from exceeding the limit of 260 characters. It's not a satisfying solution, but it works for my particular situation.
I did mention that there was a possible exception to all of this: if you can get MSBuild to avoid using al.exe altogether, then you can avoid this error.
I don't know all of the scenarios or workflows in which MSBuild utilizes this module, but I do know that it does get utilized when your application has localized resources, and somehow, some way, MSBuild uses al.exe when it is generating those resources. This was exactly my scenario, and I found this page and this page describing how you can reconfigure your localization projects such that MSBuild does not utilize al.exe. I did try the steps described in these pages and was able to verify that I no longer got this ALINK error from al.exe. However I never got my project to fully build since this reconfiguration caused other build errors to crop up. So in the end, for the sake of expediency (and because it was cleaner than performing a major refactor of my code), I went with the Jenkins workspace workaround.
However, it is interesting to note that you can get MSBuild to avoid using al.exe as long as your project is conducive to the solution given in those two links. So hopefully, if someone runs into this same issue, they might have more success than I in utilizing this method.
I have a 20+ yo .dll, written in C that none of my colleagues want to touch. With good reason, it uses macros, macro constants and casting EVERYWHERE, making the symbol table quite lean.
Unfortunately, I have to sometimes debug this code and it drives me crazy that it doesn't use something as simple as enums which would put symbols in the .pdb file to make debugging just that little bit easier.
I would love to convert some of the #defines to enums, even if I don't change the variable types as yet, but there is a genuine fear that it will cause possible issues in terms of performance if it were to change the code generated.
I need to show definitively, that no compiled code changes will occur, but it would seem that the .dll is actually changing significantly in a 64 bit build. I looked at one of the function's disassembly code and it appears to be unaffected, but I need to show what is and is not changing in the binary to alleviate the fears of my colleagues as well as some of my own trepidation, plus the bewilderment as to why any changes would propagate to the .dll at all, though the .dlls are of the same size.
Does anyone have any idea how I could do this? I've tried to use dumpbin, but I'm not that familiar with it and am getting some mixed results, prolly because I'm not understanding the output as much as I like.
The way I did this was as follows:
Turn on /FAs switch for project.
Compile that project.
Move the object file directory (Release => Release-without-enums)
Change #defines to enums
Compile that project again.
Move the object file directory (Release => Release-with-enums)
From a bash command line. Use the command from the parent of the Release directory:
for a in Release-without-enum/*.asm; do
git diff --no-index --word-diff --color -U10000 $a "Release-with-enum/$(basename $a)";
done | less -R
The -U10000 is just so that I can see the entire file of each file. Remove it if you just want to see the changes.
This will list all of the modifications in the generated assembly code.
The changes found were as follows:
Symbol addresses were moved about for apparently no reason
Referencing __FILE__ seems to result in not getting a full path when using enums. Why this would translate to removing the full path when using enums is a mystery as the compiler flags have not changed.
Some symbols were renamed for apparently no reason.
Edit
2 and 3 seem to be caused by a corrupted .pdb error. This might be due to the files being used in multiple projects in the same solution. Rebuilding the entire solution fixed those 2 problems.
I'm getting this strange behavior when I launch a program without selecting "Step Into new instance". It launches the program as if I had, requiring me to manually hit F5.
If I explicitly select to step into the new instance, I have to hit F5 twice before it proceeds. I've tried restarting, and messing around with the exception options. It's not an exception. And no, there isn't a breakpoint defined on the first line.
Has anyone seen this before?
I'm going to take some guesses here:
Try closing the solution then moving or renaming the *.suo file for this solution (the *.suo file keeps some information like breakpoint settings and certain UI states - it probably shouldn't be in version control if it is). Reopen the solution and see if it behaves any better.
If not, try the same process, but rename/move any *.vcxproj.user files (which have per-user project settings, and also probably shouldn't be in version control). If you're using some other project type than C++, there will be slightly different names - but I think they all end in *.user. There might also be *.vcxproj.<user name>.user files that you'd want to handle similarly.
If one of these turn out to solve the problem, you might want to look at the file to see if there's something that would tell you what the problem was (.vcxproj is quite readable XML, the *.suo file is some undocumented binary format, so you probably wouldn't be able to identify anything in there).
I've run into a problem that's driving me crazy, hopefully someone will be able to shed some light on it. As part of my build process I have a separate .exe that updates the VersionInfo for the file. I literally use this on more than 20+ programs, but for some reason on one of them it is removing all the existing resource information from the exe. I actually trimmed it down and I can get the exact behavior by just calling:
if ((ResourceHandle = BeginUpdateResource(Target, FALSE)) != NULL)
{
EndUpdateResource(ResourceHandle, FALSE);
}
I use the above as a simple example, but in my case I'm checking the return codes and everything is operating properly. If I run the same code against my 20 other apps, they are unaffected by it - but run it on this one and it removes the resource data.
I looked through the .rc file, removed chunks of it, rebuilt it every way I could think of, and the result is the same. I can also load it up in DevStudio, and it doesn't report that anything is corrupt, etc. The build process is exactly the same between all the apps (they're built via makefiles, so no magic happening in there either).
Has anyone else experienced this sort of behavior? It looks like other people have encountered it here.
But so far I haven't found a solution...
As part of my build process I programmatically edit the source code for the version number (in the resource source file), instead of editing the *.exe ... so I couldn't get that problem.
In my working folder of a VSS project, is it alright if I make all the files/folders writable? i.e. not readonly?
It is ok, but why should you?
The read only state is a safeguard so you can't change code that is not locked. Avoiding possible merge troubles in the near future.
Edit: Ok in the comment you said that the build failed because the file was not writable. If so, then it is very strange. Especially if the error message said something about not able to access the file.
It was probably still locked by another process and changing the readonly flag removed the lock (or it just needed the delay). But as far as I know, compilers do work excelent with read only source files.
Possible problems:
Files on network drives. If the network is slow, the compiler can have trouble accessing the file.
File still open in (an other) editor. Normally this shouldn't be a problem, but you may never know.
Some code files are generated during the build. In this case they don't belong in the version system, their source (if any) does.