[Update] I've since compiled successfully and anyone else chasing these binaries can download from here
I'm compiling version 2.06 of lzo by issuing the following command from the Visual Studio Command Prompt (2010)
b\win64\vc_dll.bat
which produces lzo2.dll without any errors, however this doesnt look like it really did produce the 64-bit dll as my 32bit C# app can still reference and call methods (successfully)
How can I compile the 64bit version?
some of the comments on this question may be outdated as the question changed but I since changed it back to the original question when it got more involved so I could mark the response as the answer
Almost certainly you will be using the wrong set of compilers; 64bit compilation isn't controlled by a command line flag - it's a completely different toolset;
Issue the build commands from the "Visual Studio x64 Win64 Command Prompt (2010)" which you will find in the Start Menu\Programs\Microsoft Visual Studio 2010\Visual Studio Tools.
e.g.
c:\> cd /d h:\temp\lzo-2.06
H:\temp\lzo-2.06> b\win64\vc_dll.bat
Related
I am getting an issue with installing the .NET SDK, at first when I went into visual studio 2019 it said that I was missing the dotnet runtime sdk so I installed it like it asked and restarted my computer. I then went on to visual studio 2019 again, and the same issue arose, I went into my command prompt and typed dotnet --list-sdks and it displayed no sdks. I have all of the runtimes installed, but it says No SDKs were found. image . I tried re-installing the sdks but the same problem stuck. I even went as far as to re-install IIS. I can't do anything without this being fixed please help soon!
Before you try a manual install, I'd check if the Path in the system's environment variables is correctly configured for your system.
Given that there's always one shared host that moves forward, it will either pick the x86 or the x64 version on your machine. This issue of not picking the right one might happen if you install multiple/different versions.
Run the where.exe dotnet command to see where the host is looking for the SDK (it's the first entry returned). If you're on a x64 machine, you want to have C:\Program Files\dotnet listed first.
If it's not, edit the Path system's environment variable to have the location you want showing up higher. Doing that should fix the issue of the SDK versions you installed not showing up when you run dotnet --info.
See The latest installed .NET SDK not found for complete instructions.
Answer above by Maira is correct and fixed the issue however for those that need a little help go to start menu, type "path" and select "Edit the System Environment variables". When that opens, under the "Advanced" tab click "Environment Variables".
Under System Variables find the "Path" variable and click "Edit". Find "C:\Program Files\dotnet" and click "Move Up" so that it is above the (x86) variable.
I managed to find the answer to this problem, and anyone else who is having this problem can most likely fix it with this solution too! So the reason it breaks is because of the way the .NET Core SDK installer works, it does not install the SDK correctly for some reason, so you have to do it manually. Go to this link, where you would normally get the installer for the SDK but rather than downloading the normal version, download the binaries version. It should download as a .zip, so extract it and then copy the contents of the folder. Go to C:\Program Files (x86)\dotnet\ and then remove it's contents, finally paste your clipboard into the folder. Now try it out, open a new command prompt or PowerShell, and type dotnet --info. It should tell you that you have all the SDK's and Runtimes installed. Keep in mind, you will have to download the newest version of the binaries, that way you have the latest version of the SDK's.
The reason this works is that you are manually pasting the SDK's into the folder, if anyone could start a ticket for the installer to Microsoft, {EDIT: MS created an internal ticket and this answer is wrong. See next answer End Edit} that would be great, and link them to this post so that they can understand what's going on. Some of you might have come here because you are fed up with reading Microsoft documentation and to be honest, so was I! Now this might not fix all the problems you are having, for example, I am still having problems with visual studio and their .NET implementation but if I or anyone figures it out, I will add it to this answer. Hope you have a great day, bye!
dotnet do not seem to match well with SDKs / runtimes with 32-bits and 64-bits. If you have both variants and want to only use the 64-bits (or generally, cant list up any SDK-s), you can try this :
Inside folder : C:\Program Files (x86)
Rename folder 'dotnet' to 'dotnet_x68'
Inside a shell (remember to either run command 'refreshenv' from Chocolatey for example to refresh your environment, if you have choco installed.. )
Enter now this command :
dotnet --info
Also list the SDKS :
dotnet --list-sdks
This fixed up my development environment. Note that if you want to use dotnet against x86 system, you might consider to instead uninstall x64 variants of dotnet runtime and sdks as dotnet do not seem to work very good from command line with a mix of them both (and avoid renaming the x86 folder of dotnet of course as suggested above.
I found that I had two program files, One called Program Files (x86) and one called Program Files. I went to Settings, About and looked at my System Type. I have a 64-Bit operating system and so I went into Program Files (x86) and found another dotnet folder. I deleted the dotnet folder and restarted Visual Studio. It Worked after that.
If you get this issue like I did on a ARM based Mac M1 or M2 then do the following.
remove this directory completely /usr/local/share/dotnet
run the installer package again
I believe this issue happened when I accidentally installed dotnet-ef x64 instead of arm64.
I have VS17 installed and have been studying C# for a while. Ever since I began, I was asked to run the ildasm.exe application, but that didn't work since in my Visual Stidio Command Prompt, when I type ildasm or ildasm.exe, it just says that the command doesn't exist.
I was able to curb that by adding the ildasm.exe application directly to the "Tools" menu of VS17 and accessing it from there and I also copied the path to the "Environment path" so that I could access it through PowerShell directly.
But now I'm being asked to access another application called dumpbin.exe, which has the same problem I initially had with ildasm.exe in the Visual Command Prompt, but this one I simply can't find the path in order to access it and I've googled and searched this website in search of the path, but I only found it for older versions of VS, which were of no use and running a search through my machine I wasn't able to find it either.
Can anyone help me find what is wrong with my Visual Command Prompt that makes these commands not available?l
With proper installation of VS you should have no problem with running Developer Command Prompt for VS 2017 and access all the commands from there.
So maybe you should check it if there are no issues there.
With DUMPBIN there might be a different case. It is part of C/C++ Build tools so you might not have them installed. Open the VS installer and check if you have this part on your machine.
And the path that this tool is installed is:
C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\VC\Tools\MSVC\14.10.25017\bin\HostX86\x86\dumpbin.exe
This is in case I got a VisualStudio2015 project and want a quick code modification and compilation. This will be really useful here where I work, we got slow PC machines and VS2015 loads at turtle speed.
thanks for your tips. :D
No, you can't. Visual Studio Code is simply an editor. You would need to invoke the .Net Compiler via the command-line tools. More information about those tools can be found on the Visual Studio Code web-site.
You would need to open the command line, point to the application directory, then do:
dotnet run
dotnet build
Please keep in mind those commands won't work until you install all the required .Net binaries, for your platform.
The intellisense on my Visual Studio Code stopped working rather suddenly the other day. I looked all over Stack Overflow for solutions, including looking at these questions:
Visual Studio Code Intellisense Suggestions Dont Pop Up Automatically
Intellisense Does Not Work Visual Studio Code in OSX Yosemite
However, everything is configured properly:
OmniSharp is running
My project.json is configured correctly
Settings were turned on properly in settings.json
There is only one project.json file and Visual Code shows that it is discovering it properly
I tried reinstalling Visual Code and updating the C# extensions app.
What is the problem?
The issue (after hours of looking) is that OmniSharp requires the Mono runtime. I had pointed at the coreclr (1.0.0-rc1-update1, coreclr x64, darwin) the other day because Mono wasn't compatible with SSL-to-Azure connections. To keep things clean, I had just uninstalled the Mono runtime, hoping to just use the coreclr.
The process for this: I first found this Git post: No intellisense on Linux for ASP .NET 5 coreclr x64 1.0.0.-rc1-final. I followed the instructions and showed the OmniSharp output (how to: Command, Shift, p in Visual Studio Code to open prompt, then type output, select Toggle Output and then change the view to OmniSharp using the dropdown). This output, when trying intellisense, showed a lot of errors being generated.
I then searched those errors and found this question/answer Visual Studio Code Designhostmanager Failed. Apparently, I needed to download the Mono runtime, specifically (in my case), Beta5, per the comment from Matt. To do this I ran dnvm install 1.0.0-beta5 in my terminal on OSX and the runtime installed and set Mono as the currently used runtime. Then, I ran dnu restore to make sure all of the proper library references were cleaned up. Finally, Visual Code prompted me for an additional restore, which I ran as well. Here is my final output (please ignore the extra Mono runtimes. I was playing around and wasn't exactly sure what the specific differences were between them):
1.0.0-beta4 mono linux/osx
1.0.0-beta5 mono linux/osx (this is the runtime)
1.0.0-rc1-update1 coreclr x64 darwin
1.0.0-rc1-update1 mono linux/osx
1.0.0-rc1-update2 mono linux/osx default
Finally, I restarted Visual Studio Code and then restarted the OmniSharp service (once again using the Command, Shift, p command and typing OmniSharp and selecting restart.
This worked. Intellisense started working again.
I had a similar issue and saw the following within the OmniSharp logs:
[ERROR:OmniSharp.Startup] The project system 'DotNetProjectSystem' threw exception during initialization.
The type initializer for 'Crypto' threw an exception.
I stumbled across this issue on GitHub, and ran the following commands using the Terminal:
ln -s /usr/local/opt/openssl/lib/libcrypto.1.0.0.dylib /usr/local/lib/
ln -s /usr/local/opt/openssl/lib/libssl.1.0.0.dylib /usr/local/lib/
After this I restarted OmniSharp using the instructions above and IntelliSense is back.
I use the x64 version of Windows 7. My application use some COM servers (usual native x86 COM Servers) that can't be loaded in x64 context. So I decided run it as a x86 application using WOW so I set platform target as x86.
But Visual Studio 2008 debugger started to show messages like "The source file is different...." for all source files when I try debug it. What is reason for this behaviour? This question was born there "The source file is different...." message in Visual Studio 2008 is result of debugging x32 apps on x64 Windows
Update: I cleaned solution, rebuilt solution, removed obj, bin and etc. folders, restarted computer, reinstalled Visual Studio... So, what else could be the problem?
Update2: If you create new Windows Application project and change target platform to x86 you will see this trouble. But if you delete Settings1.settings from project the trouble will be eliminated!!. Any Idea?
Update3: http://social.msdn.microsoft.com/Forums/en-US/vsdebug/thread/bc297668-65b4-46e8-969e-c7a6340d33b6
The error message you are getting is unrelated to debugging a WOW64 bit application. It's even less of an issue here because Visual Studio runs a 32 bit process inside of WOW64. So instead of x64 -> x86 you are actually doing an x86 -> x86 debugging session.
What's going on here is that Visual Studio is reading the checksum for the source files out of the PDB and it does not match the checksum of the files you are using to debug the application. The most likely causes for this are
Out of date PDB's
Using the incorrect source files. This is more common than you think in branching scenarios where you could easily grab the wrong version of the file.
The way I typically debug through this is
Close VS and manually delete all of the binaries and binary directories
Restart VS and rebuild
Close VS
Restart VS and attach to the running project without opening the solution
Then manually open the files
Windows 7 sets Windows Xp sp 3 compatibility mode for VS 2008 by default. Changing compatibility to Windows Vista SP2 mode have solved trouble.
You might also check the x86 build type. When you created it you may not of copied the settings from the default build and as such none of your code is building when you run your application.
Bring up the Solution Properties and check the Configuration Properties\Configuration page. Then make sure all of the projects are checked under Build for the Config/Platform combo you are using.