Two machines. Both with .NET 3.5 and the VS 2008 VC++ SP1 redistributables
A single exe which uses two signed DLLs, one in C++/CLI and one in C#
The exe loads and runs fine on one machine.
On the other, I get "Strong Name Validation Failed" on the C++ executable (HRESULT 0x8013141A)
Any ideas?
Open the command prompt as administrator and enter following commands:
reg DELETE "HKLM\Software\Microsoft\StrongName\Verification" /f
reg ADD "HKLM\Software\Microsoft\StrongName\Verification\*,*" /f
reg DELETE "HKLM\Software\Wow6432Node\Microsoft\StrongName\Verification" /f
reg ADD "HKLM\Software\Wow6432Node\Microsoft\StrongName\Verification\*,*" /f
Open the command prompt as administrator and enter the following command:
"C:\Program Files\Microsoft SDKs\Windows\v6.0A\Bin\x64\sn.exe" -Vr <dllpath>
Pay attention that the argument are case sensitive.
Source with more details: http://blogs.msdn.com/b/keithmg/archive/2012/03/20/strong-name-validation-failed-exception-from-hresult-0x8013141a.aspx
You must use the 64-bit version of sn.exe on a 64-bit machine. (C:\Program Files\Microsoft SDKs\Windows\v6.0A\Bin\x64\sn.exe)
Is the one the code runs on a "development" machine where you might have run "sn.exe -Vr AssemblyName.dll" at some stage which would allow you to use a delay signed assembly as if it were fully signed. When you transfer the delay signed assembly to another machine and run it, it will fail strong name validation because it is not fully signed.
In my case, I had the same issue with Visual Studio 2015 and I already had signed the assembly.
I fixed it by this way: Right click on the project which causes the issue -> "Properties" -> "Build" -> Change the value of the "Platform target" field.
I had to change it from Any CPU to x86 but I guess that in function of the project and the library which is failing, you should change its value to x64.
The SN.EXE is Missing in Newer versions of Visual Studio. In Visual studio 2012,
we must use "Developer command prompt for Visual studio 2012". Then Run the command "sn".
Syntax: sn -Vr *,2d58152b8e842be2
where "2d58152b8e842be2" is the public key token shown in the Error message. Somehow this alone did not solve my problem.
If someone can't find 64-bit version of sn.exe, check here:
C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.7.2 Tools\x64\sn.exe
You might be able to bypass this on development by going into the project settings -> Signing -> and unchecking "Sign the assembly".
I ran into this today while debugging against a source code copy of the Entity Framework.
I encountered this today and stumbled across http://timgeerts.blogspot.co.uk/2009/08/strong-name-validation-failed.html, which seems to be the solution.
Option 1) Turn off code coverage (in VS 2010, go to Test Settings -› Data and Diagnostics -› Untick the "Enabled" box next to Code Coverage).
Option 2) Add the signing key file to the code coverage configuration (in VS 2010, go to Test Settings -› Data and Diagnostics -› select Code Coverage and click on "Configure" at the top. This corresponds to the "keyFile" attribute for the CodeCoverage tag in the .testsettings file.)
In VS 2012, code coverage is enabled by default. It can be disabled through a .runsettings file with an appropriate exclusion. See http://msdn.microsoft.com/en-us/library/jj159530.aspx for more information and a sample file. For option 2, although there doesn't seem to be an explicit setting available in the .runsettings file, the right thing seems to happen automatically with regard to signing (YMMV). However, if you're referencing a VS 2010 .testsettings file then it will need editing as above.
Right-click on Project → Properties → Build tab → Platform Target → Select "x64"
I am working with VS.Net Ultimate 2012
and this solution helped me:
Right click on Project-> properties-> Build Tab-> switch Generate serialization assembly to off-> done
I fixed this by going to the Build menu (top pane) and say "Rebuild xxxProject.plugin" for that specific project only, contrary to building the entire solution.
Related
I'm trying to get started with c# (I've been using VS for C++ without issue) and whenever I try to open a C# Project I get this error:
The project file cannot be opened. The SDK resolver "Microsoft.DotNet.MSBuildSdkResolver" failed to run. Illegal characters in path.
The .csprj only has 7 lines!
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFramework>netstandard2.0</TargetFramework>
</PropertyGroup>
</Project>
I tried swapping the " for ' but got the same error.
Running VS2019 with /ResetSkipPkgs prevents this issue from happening and the project loads fine. However I can't find the source of the issue.
Does anyone else know what could be causing this? I'd like to be able to work on C# projects without running VS via commandline every time!
Does anyone else know what could be causing this? I'd like to be able
to work on C# projects without running VS via commandline every time!
Not sure what you did to your VS before. Maybe this issue is caused by some third party integration tools, vs extensions, or some VS Settings.
Suggestion
Please try the following steps:
1) make sure that your VS2019 has installed these two workloads
2) check System Environment Variable PATH and make sure that it has value C:\Program Files\dotnet\ and no other space keys.
Also, check if you have environment variable MSBuildSDKsPath, if so, you should check if its value exists and enter the path to check it. If not, you should modify to use the address that already exists.
If MSBuildSDKsPath does not exist, you should add it and set its value to
C:\Program Files\dotnet\sdk\3.1.xxx\Sdks
Make sure the path exists under your PC.
VERY IMPORTANT: Don't use quotes in the variable value and finish it with a \. So please check every environment and make sure that there are no garbled characters.
3) open VS IDE, click menu Extensions-->Manage Extensions and enter into installed extensions and then disable any third party extensions to check whether the issue is caused by them.
4) Reset all VS settings by Tools-->Import and Export Settings-->Reset All Settings or just run devenv /Resetsettings.
5) repair VS or update it to the latest version if there is any updates.
6) delete the .vs hidden folder under the solution folder, bin and obj folder and then test again.
================================================
Besides, you can directly add the switch into /ResetSkipPkgs into VS icon so that every time when you open VS, it will run the /ResetSkipPkgs at the same time.
Right-click on the VS2019 Shortcut icon-->Properties-->Shortcut
Add /ResetSkipPkgs into the
Click Apply and Ok to enable it.
Note: when you use it, you should open VS by clicking that icon rather than start it under VS Installer which does not support that feature).
If you start VS2019 in Start Menu, you should modify the Shortcut by my function in C:\ProgramData\Microsoft\Windows\Start Menu\Programs.
The two SDK resolvers that ship with Visual Studio and dotnet CLI are: Microsoft.DotNet.MSBuildSdkResolver and Microsoft.Build.NuGetSdkResolver.
Microsoft.DotNet.MSBuildSdkResolver is what resolves “built in” SDKs like Microsoft.NET.Sdk and Microsoft.NET.Sdk.Web. It first looks for your dotnet CLI (eg C:\Program Files\dotnet\dotnet.exe)
Here is the error message in my case:
System.ArgumentException
HResult=0x80070057
Message=Illegal characters in path.
Source=mscorlib
StackTrace:
at System.IO.Path.CheckInvalidPathChars(String path, Boolean checkAdditional)
at System.IO.Path.Combine(String path1, String path2)
at Microsoft.DotNet.DotNetSdkResolver.EnvironmentProvider.<>c__DisplayClass7_0.<GetCommandPath>b__0(String p)
at System.Linq.Enumerable.WhereSelectListIterator`2.MoveNext()
at System.Linq.Enumerable.FirstOrDefault[TSource](IEnumerable`1 source, Func`2 predicate)
at Microsoft.DotNet.DotNetSdkResolver.EnvironmentProvider.GetCommandPath(String commandName)
at Microsoft.DotNet.DotNetSdkResolver.NETCoreSdkResolver.GetDotnetExeDirectory()
You have to check the system variables PATH. Open the Command Prompt (CMD) and type: echo %PATH% and check if there are the Illegal characters in path (")
C:\Program Files\Java\jdk1.8.0_291"\bin;
Open the system variables PATH (for Windows 10 and Windows 8):
In Search, search for and then select: System (Control Panel)
Click the Advanced system settings link.
Click Environment Variables. In the section System Variables find the PATH environment variable and select it.
Click Edit.
The system variables
In my case there were the quotation marks in java_home path:
JAVA_HOME: "C:\Program Files\Java\jdk1.8.0_291"
PATH: %JAVA_HOME%\bin;
1) You can correct the path by using the short path without quotes C:\PROGRA~1\Java\jdk1.8.0_291
Edit environment variable
2) Move the following paths C:\Program Files\dotnet\ and C:\Program Files (x86)\dotnet\ up, save and restart the Visual Studio.
I need to build some application in two configurations: x86 and x64 (each config has reference on some dll, which is in 32 and 64 bit versions).
I want to build in some time(one build) and as result i want to have two folders,i.e.:
1) sln_dir/x86/
2) sln_dir/x64/
Also x86 contains 32 bit dll and x64 contains 64 bit dll.
Is it possible?And if it is possible how?
Thanks!
Well, I'd add new project configurations, and set the build type for each configuration, along with the output directory. So you might have "Debug x86" and "Debug x64" project configurations, with output directories of "bin\DebugX86" and "bin\DebugX64" for example.
That's a change that can even be done within Visual Studio, unlike most of the project file hacks I perpetrate :)
That won't build configurations with a single "build project" button press, but:
You could add a post-build step for one configuration to build the other
If this is only relevant when you build the Wix installer, I'd just script the building of that to first build both configurations
Another Visual Studio feature you should look at is the "Batch Build" option. Unfortunately it doesn't look like there's a way of saving a batch build to perform it multiple times easily :(
You can:
1) Create 2 different projects with different target CPU architecture and build solution.
Solution
ProjectA x86
ProjectB x64
Build solution. Both projects are pointing to the same source code files, naturally. There is no any source copy.
2) You can create external batch build with code like (example)
"C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\devenv.exe"
"PATH TO SOLUTION" /Rebuild "CONFIG NAME"
Where
"PATH TO SOLUTION" is a path to your solution file
"CONFIG NAME" is a configuration name, like Release86 or Relese64.
Write there code for every confifguration you need (those configuration have to be already configured in visual studio before). And just run that batch ones.
I create a new project, click compile, and get this error:
Build Failed. See the build log for details.
In the build log there is only this:
Building: FirstProgram (Debug|x86)
---------------------- Done ----------------------
Build failed.
Build: 1 error, 0 warnings
Here is what I see:
What causes this error and how do I fix it?
Lots of times dealing with this error. I just closed and reopened. It happens every time I add a solution and then delete it. I think Xamarin Ide is not a really good Ide, not in Mac at least.
In my case, i did`t Indy (or higher) License.
When i started trial period, the problem was solved.
I got the same error when trying to build. Without having noticed I had been logged out of my account, which caused the error. Curious that I wasn't prompted to relog or given information that I wasn't logged in.
Though this is an old post, maybe this could help someone.
In my case, using Xamarin Studio 6.1.4 (build 1), I unchecked
the 'Use MsBuild engine ...' check box under Project Options > Build > General and
the problem disappeared.
I searched for solution online for similar problem, but none solved my problem, then I tried this:
Tools >>> Options >>> Projects and Solutions >>> Build and Run
Then I changed MSBuild output and MSBuild log to Detailed.
Rebuild and the error message will show.
cd into the project path, and hit msbuild on it.
You will then see the error details in the console STDOUT.
I had the same problem after upgrading Xamarin, and in my case it happened even for a x86/desktop Console Application. Turned out to be because I didn't have 4.5.1, which was required by the newer version (I had only 4.5 I think).
I found this entry in the log:
Unregistered TargetFramework '.NETFramework,Version=v4.5.1' is being requested from SystemAssemblyService, returning empty TargetFramework
After googing this error I found https://stackoverflow.com/a/38102386/492336, and the solution was to download .NET 4.5.1 and it worked after that!
I just ran into the same problem using Visual Studio Community for Mac. The system was out of disk space. Freeing up some disk allowed a build to complete successfully.
Try the following options from Build menu:
Clean All
Rebuild All
Then build it again.
If won't help, check your log files for details by going to Help menu and Open Log Directory.
For example by dragging & dropping the log folder into newly opened Terminal window, and run:
tail -f *.log
then run the build again and check the reported logs. Hit Control-C on Terminal when finished.
For better visibility, run:
tail -f *.log | grep -C5 -i error
You can also try to clear cache folder of VisualStudio, e.g.:
$ lsof -p $(pgrep VisualStudio)
$ rm -fr ~/Library/Caches/com.microsoft.visual-studio
I downloaded and installed the packages shown below in the order listed:
JDK 1.6: http://www.oracle.com/technetwork/java/javase/downloads/jdk-6u31-download-1501634.html Please choose the jdk-6u31-windows-i586.exe installer from the list above.
Android SDK: http://dl.google.com/android/installer_r20-windows.exe After the main installer is done, please open the SDK Manager and install the following platform APIs: 7,8,10,12,14
Mono for Android SDK: http://download.xamarin.com/MonoforAndroid/Windows/mono-android-4.4.55.104956787.msi
Reboot Xamarin.
Try building your project from the Powershell command line.
dotnet build
Then, build errors will appear in the command line output.
I encountered this issue today in Visual Studio for Mac 2022 with a Xamarin Forms 5 project. In my case, going to the Solution properties, under Build → General, and unchecking "Build with MSBuild on Mono" worked.
(This might be similar in spirit as #JackGriffin's answer, but it seems to be a solution property rather than a project property.)
I have a WebApplication which contains reference to WCF services.
While building using Visual Studio 2010, Build fails without any error or warning. However building the .csproj using MsBuild is successful.
Can't figure out what should I try in Visual Studio, to resolve / diagnose the issue. Can you please help out?
I find out that the build has been failing,
From text displayed in status Bar.
From output window:
========== Build: 0 succeeded or up-to-date, 1 failed, 0 skipped ==========
The output tab includes configuration details.
------ Build started: Project: <projectName here> Configuration: Debug Any CPU
I noticed that if "Build + Intellisense" is selected in the Error List, it causes the error messages to be swallowed.
Change this option to "Build Only", and all error messages will be displayed:
I don't know if this is a bug in Visual Studio or what, but it certainly revealed hidden error messages that were the key to pinpointing the failure for me.
Some, like Richard J Foster, have suggested increasing the "MSBuild project build output verbosity" setting to "Diagnostic" (the highest possible option), but this didn't solve the problem for me, as Visual Studio appeared to be suppressing the error message(s) themselves.
As an alternative, you may try to use the raw output messages from the "Output" tab, which haven't been filtered by Visual Studio. Either do an in-place search for the strings "error" and/or "failed", or copy all of the output to your favorite text editor and do a search there.
To ensure that the Output window appears each time you do a build, you can go to Tools → Options → Projects and Solutions → General, and ensure that the option "Show Output Window when build starts" is checked.
As an additional troubleshooting step, it is also possible to build the project from the PowerShell command line by running dotnet build. This will show you the complete build output, including any errors that Visual Studio may be hiding.
I just ran into a similar situation. In my case, a custom action (from the MSBuildVersioning package available on Nuget.org - http://www.nuget.org/packages/MSBuildVersioning/) which appeared in the csproj file's BeforeBuild target was failing without triggering any error message in the normal place.
I was able to determine this by setting the "MSBuild project build output verbosity" (in the latest Visual Studio's Tools tab [Path: Tools > Options > Build and Run]) to "Diagnostic" as shown below. This then showed that the custom action (in my case HgVersionFile) was what had failed.
Here are some things that you can try:
If your solution contains more than one project, try building each project one at a time. (You may even want to try opening each project independently of the solution.)
If applicable, ensure that all of your projects (including dependencies and tests) target the same version of the .NET Framework. (Thanks to user764754 for this suggestion!)
Tip: Check Tools → Extension and Updates to ensure that your packages are up-to-date.
Ensure that all dependency projects are built to target the same platform as your main project.
Try restarting Visual Studio.
As suggested by Bill Yang, try running Visual Studio as Administrator, if you aren't already. (If you are already running Visual Studio as Administrator, perhaps try the opposite?)
Try restarting your computer.
Try "Rebuild All".
Run "Clean Solution", then remove your *vspscc* and *vssscc* files, restart Visual Studio, and then "Rebuild All".
As suggested by Andy, close Visual Studio, delete the .suo file, and restart Visual Studio.
As suggested by Arun Prasad E S, close Visual Studio, delete the .vs folder in your solution directory, and then re-open Visual Studio. (This folder is auto-generated by Visual Studio and contains cache, configuration settings, and more. More details can be found in these questions: Visual Studio - Deleting .vs folder and https://stackoverflow.com/q/48897191.)
As suggested by MrMalith, close Visual Studio, delete the obj folder in your solution directory, clear your temporary folder, and then re-open Visual Studio.
Delete the hidden .vs folder & restart Visual Studio. That worked for me.
I want to expand on Sasse's answer. I had to target the correct version of .NET to resolve the problem.
One project was giving me an error:
"The type or namespace name 'SomeNamespace' does not exist in the namespace 'BeforeSomeNamespace' (are you missing an assembly reference?)".
There was no error in the Error List window but the assembly had a yellow warning sign under "References".
I then saw that the referencing project targeted 4.5.1 and the referenced project 4.6.1. Changing 4.6.1 to 4.5.1 allowed the overall build to succeed.
Nothing was working for me so I deleted the .suo file, restarted VS, cleaned the projected, and then the build would work.
I tried many things like restarting Visual Studio, cleaning and rebuilding the solution, restarting the PC, etc., but none of them worked for me. I was finally able to solve the problem by doing the following:
First of all, make sure all the projects in your solution (including tests) are targeting the same .NET version. Then:
Save pending changes in the project and close Visual Studio
Find the exact location from file explorer and find "obj" file and open it,
Then, delete all the included files (some files won't remove, it doesn't matter, just skip them).
Use run command (by pressing Windows Key + R) and type "%temp%" and press enter to find temporary files.
Finally, delete them all.
On other possibility is that Visual Studio needs to run as Administrator, this might be related to deploying to local IIS server or other deployment need.
Just for the sake of completion and maybe helping someone encountering the same error again in the future, I was using Mahapps metro interface and changed the XAML of one window, but forgot to change the partial class in the code-behind. In that case, the build failed without an error or warning, and I was able to find it out by increasing the verbosity of the output from the settings:
In my case (VS 2019 v16.11.20), disabling Text Editor->C#->Advanced->Enable 'pull' diagnostics in the options solved the issue.
Double check for _underscore.aspx pages in your project.
I had a page and code-behind:
`myPage.aspx` and `myPage.aspx.vb`
when building the project, I'd get errors on the .aspx.vb page stating that properties defined on the .aspx page didn't exist, even though the page itself would build fine and there were NO OTHER ERRORS showing in the output (even with diagnostic level build output).
I then came across a page in the project that was named the same thing but with an underscore: _myPage.aspx - not sure where it came from, I deleted it, and the solution built fine.
I have a C# 2010 WinForms application using .Net Framework 4.
I am using Eazfuscator.NET to obfuscate this application. If I obfuscate the executable manually, everything works fine.
When I try to make the program obfuscate itself on every build by dragging the project onto the green part, everything works fine and this is output:
Protecting project 'Roster Manager.csproj'... done
Protected project will be obfuscated automatically during the build in Release configuration
Please restart Visual Studio to complete the installation of Eazfuscator.NET
After that, I close VS, start it again, clean the solution, rebuild it and run it. The program works but it is not obfuscated, as proved by decompiling it using Reflector 7.
I am building it in Release as requested by the program.
Searching the web didn't help so maybe if someone ran into this problem before might have a fix to this issue.
Eazfuscator add this line to the PostBuildEvent (Word Wrapped for legibility, but it is one line) of your project. (Right click on Project -> Properties -> Build Events.)
if /I "$(ConfigurationName)" == "Release" Eazfuscator.NET.exe "$(TargetPath)"
--msbuild-project-path "$(ProjectPath)" --msbuild-project-configuration "$(ConfigurationName)"
--msbuild-project-platform "$(PlatformName)" --msbuild-solution-path
"$(SolutionPath)" -n --newline-flush -v 3.2
Check if it is present and if your release configuration is really called "Release".
Finally managed to fix it. Seems that disabling the User Account Control resolves the issue.
A quick Google search will give more details into how to do this.
If you're using a version control system like TFS, .csproj file may be locked.
So you'll have to unlock file by checking it out or unchecking "Read-only" box from file properties.