Some quick background. I need to compile a .net program written by a coworker in Spain. His code contains characters that my version of msbuild tags as invalid (such as the ñ), but msbuild on his computer compiles the project just fine.
Lastly, he is on windows and I am on a mac, but I may need to run the compilation on a windows machine in the future. Both my mac and my potential windows machines are US versions.
How can I get msbuild to recognize the characters as valid ones?
Related
I have the following as part of a "Deploy" project which I run manually from a batch file using msbuild.exe (VS2017).
<Target Name="ZipRelease"
DependsOnTargets="getversion;gettime">
<MakeDir Directories="$(ReleaseDir)" Condition="!Exists('$(ReleaseDir)')" />
<ZipDirectory Condition="Exists('$(BuildDir)')"
SourceDirectory="$(BuildDir)"
DestinationFile="$(ReleaseDir)\$(MODNAME)-$(DLLVersion)_$(CurrentDate).zip" />
</Target>
On one PC I use the Community Edition of VS2017. I may also have installed VS2019 on that machine (no way to check for a couple of weeks). Crucially the batch file forces the use of VS2017. On another PC I have VS2017 Professional.
On the PC using the Community Edition, this task creates correct zip files which use forward-slashes as the path separator. On the PC using VS2017Pro, the task creates zip files with back-slashes which is obviously against the spec and causes lots of problems (the resulting ZIP is deployed on Linux as well as Windows).
This thread indicates DotNet 4.6.1 or later fixes the path separator used when creating ZIP files. I specify ToolsVersion="15.8" as part of the Project configuration (minimum version for the ZipDirectory task), but how do I force the DotNet version for an MSBuild Task?
I've tried uninstalling all earlier versions of Dotnet SDK/target framework from the PC to no avail.
There's also an override documented (Switch.System.IO.Compression.ZipFile.UseBackslash), but that only applies to applications, not MSBuild Tasks.
As seems usual with MS stuff, there's inconsistencies everywhere and my Google skills are insufficient to find an answer so grateful for anybody being able to point me in the right direction.
Installing VS2019 fixes it.
It seems my script automatically configures itself to use the newest version of Visual Studio instead of forcing itself to VS2017 as I had originally stated.
Even though all DotNet version numbers as reported by the build script for its runtime framework are still the same, something is obviously different between running in a VS2017 vs VS2019 environment.
It would be very very nice to figure out exactly what and whether it's possible to force the VS2017 intall to use that as well..
Try to use
<ZipDirectory Condition="Exists('$(BuildDir)')"
SourceDirectory="$(BuildDir)"
DestinationFile="$([System.String]::Copy($(ReleaseDir)\$(MODNAME)-$(DLLVersion)_$(CurrentDate).zip).Replace('\', '/'))" />
Actually, all my agents are using back-slashes for path. And windows always uses back-slashes for path, so I wonder if you have made some changes to your windows or VS IDE to use forward-slashes for that PC.
Linux uses forward-slashes but Windows do not use that by default.
You can open the folder of the C disk to check whether the path uses forward-slashes. And make sure whether you have run some cmd commands to use that.
Open VS IDE, compare with the two versions from the two PCs, open Extensions-->Manage Extensions-->Installed to check whether you have installed some extensions to cause that.
Is it possible to get editbin.exe installed on a build server (running TeamCity 9.*, although I don't think that's particularly relevant) so that we can modifiy the TSAWARE flag of a C# exe after it's built?
It appears that our only option is to take a code-based approach (https://msdn.microsoft.com/en-us/library/microsoft.visualstudio.vcprojectengine.vclinkertool.terminalserveraware.aspx), and I'm not even certain that's a possibility since it appears to just use a .Net wrapper for the C++ linker, which is the whole problem here. If I could do that, I could just set up the project to set the linker option, but since we're using C#, there is no C++ linker.
I'm fairly certain that, even if it worked, copying editbin.exe from a developer workstation isn't permitted by the EULA, and we'd rather avoid needing to install VS (properly licensed of course) on the build server.
Install Visual Studio Express. This edition comes with the C++ Tools.
Don't know if this is 100% compliant with the eula.
When running a project in Test or Debug configuration in VB.NET using Visual Studio 2012, sometimes it gives the following error as the reason for "Build Failed"
Error 1 Could not copy the file "obj\Debug\MyProgram.exe" because it was not found. MyProgram
There are no issues with the code as it was just compiled seconds before this (sometimes I start the program again just to see how everything gets laid out visually and then go back to the code to make Location adjustments)
What I found is this. If I wait , when I go to test compile again -- it just magically starts working again -- Only to fail again later.
Sometimes, I can get 10-15 good compiles before it wigs out.
About my system configuration:
I do not have any other version of Visual Studio or standalone .NET language installed
The paths are set correctly (else it would never compile in the first place.. not just occassionaly fail)
The program can be a simple program with absolutely no code added (aka... New > WinForms Project > Compile)
The project, language (and all requirements), and project output path are on a local drive that is connected directly to the PC internally (using C:\code* for projects and the standard install location for Visual Studio 2012)
I checked the smart data and scanned my hard drive for any errors ... none ever encountered. The temperature of my system (CPU), and the drive is around 25-30 degrees C.
I am really baffled as to why this happens and at random. I have also tried completely clearing out the bin/ folder, and even Moving the project or repointing where the compiled output path is.
Deleting the .suo file helps sometimes, but not all the time.
I believe this is something that may be able to be tweaked in the UI somehow, however I do not know anything about manually linking and compiling programs.
Lastly -- it does not matter whether I run VS in "Administrator" mode (elevated privileges) or as a user.
Some methods that may help you
Have you tried to reinstall Visual Studio. If that does not work you may need to install some of Windows Updates, the compiler may be missing some essential libraries/references to compile your application.
Check your .Net Target Framework, setting your application to a new framework that you don't have installed can stop the application from compiling yet even stop it from being debugged, having a compiler that is to low, this may come with errors for the compiler but not for the IDE/Visual Studio to notice.
Try cleaning your project solution's output folder by right clicking your solution then try to rebuild your project/solution.
Check your compilation references in your project's properties, check if a reference added is not on your computer
Reinstall/Update .Net Framework, same here some requirements may be missing from your installation
Try installing a newer version of Visual Studio, try Vs2013 - this contains various improvements and fixes, Visual Studio 2015 is fast approaching, a recommendation install VS2015 when the full version gets released it will contain a lot of useful features for future .net programming.
Create an new Administrator account and Run VS with Administrator rights and try compiling then, this fixes some of problems in vs and other microsoft products, it might work here.
Install all of the .Net Frameworks from the lowest to current 4.5, this may help when some of the used references/libraries are not on your local hard drive.
if none of these methods work, i would not know of the problem one last thing you could try is installing Windows to another hard drive and try using that installation of windows and see what happens... Hope this helps.
Best regards!
I faced this kind of problem because of my virus guard
blocked my application(but it is not have any harmful code :) )
exclude your project folder from virus guard
or
simply disable it(not recommended)
I'm trying to compile MPIR (the Windows-friendly fork of GMP) from the command line. My setup is pretty bog standard, Windows Vista 32-bit, Visual C++ 2010 express edition, and I'm just going for a completely vanilla 32-bit static library build, not trying to use the IDE. The information I could find with a Google search says:
Install the appropriate version of yasm.
Go into build.vc10
Configure.bat
Make.bat
I managed to get as far as step 3 seeming to work, and past the first obstacle in step 4, but now it's tripping up on this line in make.bat:
%MS_BUILD% gen-mpir\gen-mpir.vcxproj /p:Platform=Win32;Configuration=Release
As far as the searches I've run can determine, there is no gen-mpir anywhere in the entire directory tree, nor any other reference to such. What am I missing?
Answer from the good folk on the mpir-devel mailing list: http://groups.google.com/group/mpir-devel/browse_thread/thread/488233bc8face88a
I have a VB.Net 1.1 application works just fine after compiling in Visual Studio. However, I want to use ILMerge to combine all the referenced assemblies into a single executable just to make it easier to move around. After I send it through ILMerge and try to run it I get the error
"Strong name validation failed for assembly.exe" .....
But none of my stuff is strong named! I saw this post here: Strong Name Validation Failed and tried running it through 'sn.exe -Vr merged.exe' but that gives me this error:
"merged.exe does not represent a strongly named assembly"
Has anyone else had this problem before? How do I fix it?
UPDATE:
I'm starting to feel like Strong name validation isn't the real problem here. I'm building against .NET v1.1 and running on a machine where that is the only .NET version installed (happens to be Windows 2003). The merged executable appears to die with that error on every Windows 2003 machine I try, but if I try to run it on a more modern OS (Vista) it at least starts, but that's not really a good test since the environment isn't fit for a real test.
I have verified that my app.config has the correct settings (specifying required and supported runtime version of v1.1.4322)
I use the /targetplatform:v1.1 option when running my assemblies through ILMerge.
ILMerge is definitely causing the problem (i.e. it works fine before I merge), I just don't know how to fix it.
I had to find and download a very old version of ILMerge (v1.1) in order for my merged binary to work; there must be a bug in the way the current ILMerge application builds .NET 1.1 assemblies. Thankfully we had one internally because I would probably have never found it online.