I'm trying to automatically download Nuget.exe from a Rakefile, in order to minimize the amount of initial setup needed to run my samples on GitHub.
I've understand how to download a file (I'm using HTTParty) and how to save a binary file (using the b flag on File.new) but now I've got problem running Nuget.exe. In particular:
if I launch it directly or from PowerShell, the executable runs fine;
if I launch it from cmd or from a Rakefile (which in turn runs cmd), Windows tells me that the program "stopped working".
I reproduced the same behavior with the Nuget bootstrapper, so I thought that the cause was some configuration in my computer.
It then occured to me that I installed ansicom, a library to handle ANSI sequences. I disabled it and then Nuget started without any problem.
Related
I am attempting to run an .sh script (which itself is supposed to kick off a series of unit tests in flask) from within Visual Studio Code running in Windows 10 and for some reason no matter what I try it only opens the file for editing instead of actually running the file.
This is the exact command I am typing:
C:\Users\my.user\MyRepo>.\scripts\run-unit-tests.sh
Here are my notes:
This is a brand new installation of Windows 10 where I believe I have enabled WSL2
I am completely unfamiliar with doing development from within Windows (coming from a Ubuntu/Linux background)
My goal is to run this script from within the built in terminal in VS Code, however I have also tried running it from a cmd prompt and also from powershell and both of those also result in opening the file in VS Code.
Addendum: more notes:
I actually have two windows machines. one is my personal machine, the other provided by my work. For whatever reason this file works fine on my personal machine but does not on my work machine. Also the bash script is in a repo which was created by others at my company so i'm certain that this can be made to run without modifying the .sh file itself.
I figured out what was going on.
In windows there are default file associations. Mine was set up to run Visual Studio Code for the .sh file extension. Also, windows does not know how to handle .sh files by default. There were likely many potential fixes for this however the one that worked was for me to re-associate the .sh file extension to open with Git Bash which I happened to also have installed on this machine.
Thanks all who tried to help.
In-House developed .exe file is failing in container, it prints no error, and just returns the exit code -1073741515. The exe seems to be running fine on other machines. I understand this error code means it's missing a DLL File or Library but I don't which one.
It's a windowsservercore based container. Running no other application except this .exe, and running it on Command Prompt, although Powershell also return same exit code.
I took a dump of it using dumpbin tool (which comes with Visual Studio), to check which DLL files it uses, and my container is also having all those DLLs
I tried Dr. Memory tools like drmemory.exe and it says the WARNING: libraries needed by the application are missing. Check that it runs successfully on its own and check that all needed libraries are in its directory or on the PATH.
I am running out of options to troubleshoot. How can I find what is causing this .exe to fail or any missing dependency?
I am trying to get some code running which uses make. I've downloaded and installed both MinGW (standard 32 bit) and TDM-GCCs flavor of MinGW on my 64-bit Windows 7 machine.
When I run make (i.e. mingw32-make.exe) in Administrator mode, I get the following error message:
Windows cannot access the specified path, or file. You may not have the appropriate permissions to access the item.
The weird/scary part is that, upon running, it immediately deletes the exe file.
I ran a checksum SHA1 as recommended in the comments using the Microsoft (R) File Checksum Integrity Verifier V2.05:
C:\path\to\folder>fciv.exe -sha1 mingw32-make.exe
//
// File Checksum Integrity Verifier version 2.05.
//
c8ae5c780ab7bed652883d6443b5bfe5e23d30c9 mingw32-make.exe
I don't understand what this output means, but maybe it's helpful to someone.
Notes:
This happens regardless of where the file is located on my pc.
This behavior is specific to the make program (others such as gfortran and gcc appear to be working fine)
Renaming the file makes no difference.
I am an administrator on the pc
Same behavior when I run the program from the explorer or command line.
My anti-virus program (Avast) does not detect any problems with the file when I scan it.
I got the MinGW setup file from this SourceForge page.
I got the TDM-GCC web installer from this page.
The file size is 219,662 bytes (from both the main MinGW and TDM-GCC packages)
I have run make from the command line where I have started the command prompt by way of selecting Run as Administrator in the context menu.
I have also tried to run make by selecting Run as Administrator when I have it selected.
I run the command mingw32-make when this behavior occurs. I have also tried renaming it to things like make and foo with the same result.
The first time this happened with both MinGW it deleted the original file and I re-installed it using the mingw-get application. From thereon after I started making copies of the original mingw32-make for testing.
For the make executable, I have all permissions (including Read & execute) except the special permissions field.
After using the process manager I found out it was indeed Avast that was the problem :S A couple of lines revealed avast actually deleted the file before windows got around to executing it, which was the reason for the windows message. I put Avast on 'Silent Mode' a while back; I thought the only purpose of this mode was to suppress notifications about minor updates, but apparently it also gave Avast permission to deal with 'threats' silently as well.
After figuring that out the solution was straightforward. I just went into the settings and created an exception for the mingw32-make.exe file. It now runs without issue.
Thanks very much for your help everyone!
User account has administrator privilege but when user started to work , not all privilege are taken in account , just start your application for compiling with run with administrator mode try this : https://technet.microsoft.com/en-in/library/cc781763(v=ws.10).aspx
I am trying to build a VS .sln that has multiple C++ .vcproj's in it. The solution file is generated using CMake and I've got this part working in Jenkins (with the CMake builder plugin). To build the solution file, I am using msbuild. I am able to build the solution using both Visual Studio and from the command line with the following command:
C:\Jenkins\workspace\SonioTest>"C:\Windows\Microsoft.NET\Framework\v4.0.30319\msbuild.exe" /t:Rebuild bin/SonIO.sln
This builds successfully (on the same machine that Jenkins resides).
However, I am trying to automate this portion of the build in Jenkins and the build ends up failing with a couple of C1083 errors ("Cannot open source file: '..\path\to\file.ext': No such file or directory). I have tried using both the Jenkins msbuild plugin and using the exact same command that works in the terminal as a "Execute Windows batch command" build step, with the same result.
When using the Windows batch command build step, I can see in the log that the command being executed:
C:\Jenkins\workspace\SonioTest>"C:\Windows\Microsoft.NET\Framework\v4.0.30319 msbuild.exe" /t:Rebuild bin/SonIO.sln
... is exactly the same as the one that works from the command line, including the working directory.
I am running Jenkins as a service and I have the service logon as my account (with administrator privileges). Anyone know what directory Jenkins will execute batch commands out of?
Any ideas why I'm seeing this difference of behavior between Jenkins and the command line?
This is as much a workaround as a solution, but I ended up using devenv instead of msbuild and it works fine.
I know that this hints strongly as it being an environmental issue, but since it's not a problem to have VS installed on the build server, I decided to save the time that would be spent in the msbuild rabbit hole.
The environment being used by the account that the Jenkins slave agent is not the same environment as you use when doing the same command line from a prompt. Compare the two environments, note the difference, then add them to the Jenkins job.
To get the environment of the slave while running, have it do a "set" from a Windows Command Prompt
Without knowing much about VS build, it looks mostly like an environment setup.
My first advice would be to make sure, in Jenkins, you change directory to the same directory you ran the good command from and try it then.
Also, might want to try running Jenkins as a standalone app first.
And as a service, maybe allow service to "interact with desktop".
I may be late to the party, but I still ran into this problem on a new Jenkins setup on Server 2016.
My solution was to use the MSBUILD straight from the VS2017 installation C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\MSBuild\15.0\Bin. No more errors.
I am quantitatively studying various metrics associated with automated tests. Chrome seems to have a reasonable set, so I wanted to add it to my data set. I downloaded the Chrome source code and tried to build it with VisualStudio but got several hundred errors--types not defined, identifiers not defined, etc. Has anyone out there succeeded in building Chrome under Windows? Are there tricks I need to know?
From the Chromium dev page:
Compilation failures
Some common things to think about when you have weird compilation failures:
Make sure you have SP1 for Visual Studio 2005. It's required. Really.
Sometimes Visual Studio does the wrong thing when building Chromium and gets stuck on a bogus error. A good indication of this is if it is only failing for one person but others (including the Buildbots) are not complaining. To resolve this, try the following steps:
Close Visual Studio.
Sync to the tip of tree and ensure there are no conflicts ("svn st" should not show any "C"s in front of files that you've changed).
If there were conflicts, sync again after resolving them.
Manually erase the output directory (chrome\Debug and chrome\Release. Using the command line, you can use "erase /S /Q Debug Release" from the chrome directory to do this, or "rm -rf Debug Release" if you have Unix-like tools installed.
Restart Visual Studio and open the Chromium solution.
Rebuild the solution.
If it still doesn't work, repeating this process probably won't help.
chrome_kjs.sln tempfile problems
If, while building JavaScriptCore, you see errors like:
3>Error in tempfile() using /tmp/dftables-XXXXXXXX.in: Parent directory (/tmp/) is not writable
3> at /cygdrive/c/b/slave/WEBKIT~1/build/webkit/third_party/JavaScriptCore/pcre/dftables line 236
3>make: *** [chartables.c] Error 255
...it's because the Cygwin installation included in the Chromium source is having trouble mapping the NT ACL to POSIX permissions. This seems to happen when Chromium is checked out into a directory for which Cygwin can't figure out the permissions in the first place, possibly when the directory is created from within a Cygwin environment before running mkpasswd. Cygwin then imposes its own access control, which is incorrectly restrictive. As a workaround, do one of the following:
Edit the NT permissions on third_party\cygwin\tmp to allow Modify and Write actions for Everyone and machine\Users. Cygwin is able to figure this out. Or,
Figure out what went wrong with your checkout and try again - try doing the checkout from cmd instead of from a Cygwin shell, then verify that the permissions aren't completely blank in your Cygwin installation. Or,
Bypass Cygwin's access control (NT's will still be in effect) by editing webkit\build\JavaScriptCore\prebuild.bat and webkit\build\WebCore\prebuild.bat to include the following line before invoking anything that uses Cygwin:
set CYGWIN=nontsec
Only one of these solutions should be needed.