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.
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'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.
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 am having a problem like this one:
http://svn.haxx.se/tsvnusers/archive-2008-07/1051.shtml
Except that the app is our own (sorry, won't give you confidential details). Although, it is not our fault that SideBySide is so flawed.
Anyhow, version X works and version Y bombs right at the start. I am facing the task of walking through a bunch of directories and up to 100 dll files to figure out what the difference may be.
It looks like there is a conflict between two dll files which load two different versions of another dll file.
I would appreciate your help with a Python / other snippet for extracting a manifest from a given file. Thanks!
EDIT: By the way, I did find a way: I can run the following command (mt.exe is part of Visual Studio 2008 Tools): mt.exe -inputresource:MyFile.dll;#2 -out:MyFile.dll.extracted_manifest.txt.
This is a good start, but there are two problems with it:
There can be multiple manifests embedded (In my understanding): #1, #2, #3, ... - I do not know which ones and how many ahead of time. What is the maximum?
If I take a guess and run mt.exe with that parameter, I get a failure. Dealing with these errors would make the script longer.
Could someone shed some light on this please?
ANOTHER EDIT: Ah, never mind! 1 is for .exe, 2 is fo dll and that is it. I guess I know what to do now. However, if you have a solution which beats mine, or if you have automated calls to mt.exe from a Python / other script, then feel free to share it.
A manual brute-force (clicking) approach worked faster. Took only a few hours.
I look at a lot of small Java programs. It would be convenient if I could set up a directory (or directory structure) on my Mac where any time I add a .java file, javac automatically runs and attempts to compile that file. I've briefly looked into Automator actions, but found nothing that fits the bill. Then I got to thinking: on my PC, I would use the .Net FileSystemWatcher class and write the code myself. But before I try that on my Mac with Mono, I want to ask the community for other ideas. Any advice is appreciated. Thanks.
In JDK6 you can programmatically compile, so you could write your own program to do this, which may be slightly better than doing it in mono.
So you would just have a program that is always running, it looks for either any new files or a file that has been changed since the last check and then just compiles them, and you may want it to pass information to a dashboard window when there are errors, and perhaps some status info so you know it is working.
http://binkley.blogspot.com/2005/09/programmatically-compiling-java-in-jdk.html
If you have all the .java files available at the start, you could write a shell script to compile them all in one run -- in different directories if you need to.
If you explained why you would want this, maybe I/we could be more helpful.