After installing the Developer Preview our Custom FxCop rules project won't build as the following Dll's can't be found:
FxCopSdk.dll & Microsoft.Cci.dll
It turns out that this is a red herring, looking at the project for the custom rules on other's machines, it doesn't build without re-referencing the aforementioned dll's correctly (so that's normal) the real problem is that our existing build is using the VS11 code analysis.
I've now removed VS11 but it's still not working!
Any ideas?
Update:
Since installing vs11 my build batch is defaulting to the VS11 version, this isn't happening on other who have installed the preview [and they are also using x64 windows 7]
I've seen problems with VS2012 interfering with VS2010 on a few machines so far it's been easy to flatten the machine and rebuild from scratch.
Related
We've upgraded from Visual Studio 2015 to 2019 and did an enhancement using VS 2019. Now, we have in the verge of build and packaging the application in build machine, but the problem is, our team leader is saying that we can use Visual Studio 2015 on the build machine to build the project and when I told him, what is the use of upgrading 2015 to 2019 and he told me that it doesn't matter.
Now, I need few good reason to prove that building a project using VS 2015 which we've developed using 2019 is not a good idea. Can someone let me know few points?
Thanks.
Now, I need few good reason to prove that building a project using VS
2015 which we've developed using 2019 is not a good idea. Can someone
let me know few points?
For your situation, I must first declare that you would better use build engine of VS2019 to build VS2019 projects. And as we know, the build engine of VS supports downward compatibility which means the higher version can build the projects of lower version. For an example, you have a lower version projects which created by VS2015, you can use the VS2017,VS2019 to build this project successfully.
Therefore, it is not recommended to use the old version tool to compile the new version of the project.
In more detail, the build engine is also based on the content of your current project and the code in the content (each version of VS has slightly different rules for the code being developed and the content of the file) to finally generate the output file based on the rules of the build engine (means the target order, existing in the .props or .targets file of xxx.xxporj).
Like this:
The difference between the rules in different versions of the build tool is the different target commands in these import files
Second, if your project code only uses a few passing statement rules, you can compile using VS2015. However, if you are using some of the language rules that are specific to the higher version, you can only use the build tool in VS2019, and you will inevitably use its rules for projects that you are developing in VS2019.
Third,VS2019 contains some new workloads and new project templates while the old version VS2015 did not have. For an example, VS2019 can creating the new Net Coreproject while VS2015 did not contains the new workload, So build tool for VS2015 cannot build this type of projects. Because of this, some changes in the new release will also have an impact on msbuild. To avoid unprovoked problems, we recommend using VS2019.
In addition, l agree with ToddN. If you think VS2019 is too big and too cumbersome to download to the build server, you can just download the build tool for VS2019. You don't have to download the huge VS IDE because current VS compilation tools can be downloaded separately. When you use it, you only need to install the corresponding project's workload.
I recently upgraded from Visual Studio 2012 to 2017 (updated to version 15.3.5) and have some issues with the IDE.
In a certain project, I don't get error underlining.
and in the Error List pane, "Build Only" actually shows more information than "Build + IntelliSense"
Also, with "Build + IntelliSense" selected, I can only see the compiler error in the Output window. Here is the error list after a failed build
but the output window has this:
3>------ Build started: Project: ..., Configuration: Debug Any CPU ------
3>C:\Checkout...\MainForm.vb(454,27): error BC30311: Value of type 'Module1.aClass' cannot be converted to 'Module1.bClass'.
This doesn't happen on all projects. I made a new project to see if I could reproduce, and I can't. Here is a new project with the same code, where the error is underlined in code and "Build + IntelliSense" works.
I have even sorted the xml in the vbproj files and "diffed" the offending project vs the new project, and there is no obvious difference which would cause this. Both reference the same compiler. Both projects target .Net 4.6.2 and are set to compile for x86 only. The offending project references a few other projects (C# and VB.Net) plus a third party dll and a nuget package. Aside from these differences there is nothing else.
Other projects (C# and VB.Net) in the offending project's solution work fine.
I have seen similar issues talked about online but no fixes have worked for me. I have tried the "Repair" option in the installer. I then uninstalled Visual Studio and reinstalled.
Update:
Changing the target framework seems to have some effect. A project with this behavior was targeting 4.6.2 and showing no errors, and when it was changed to 4.7, it showed a compile error. Then changing back to 4.5 it showed an error. Then changing back to 4.6.2 it showed no errors. Repeating the process proved to be non repeatable. 4.7, 4.5, 4.6, 4.6.2 - whatever, now all show no errors.
It's also important to link this Microsoft page https://developercommunity.visualstudio.com/content/problem/7759/no-errors-displayed-in-the-error-list.html as many other people seem to have a similar issue.
I have solved the problem, at least in my solution.
I was playing around with project references, and found that when a particular project was not referenced by another project, I got error underlining. I went through a process of changing framework version targets until something worked.
All my projects had previously been targeting .NET 4.6.2. By targeting 4.7 on all the projects, I now get proper error underlining and reporting in the Error window.
I'm not sure if this is a solution for everyone and it will take some additional work on my end to deploy my project to production but I can accept this.
I guess this is related to targeting 4.6.2 using Visual Studio 2012 and upgrading to 2017. Maybe something was not set properly if/when the projects were upgraded.
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've been working in an engine in Visual Studio 2012 that supports rendering with Direct3D 9 and Direct3D 11. However I'm getting some new people to help with the project and they would prefer to work on Visual Studio 2010 because that's the version they own and use. So I decided to convert the project to be built with VS2010's v100 platform toolset.
I'm getting close to getting it to work but I can't include DirectXMath.h, necessary for the DirectXTK and some utility functions I'm using. It's part of the Windows 8 SDK and included in VS2012, but VS2010 doesn't seem to find it.
Anyone knows how to get it to be included using environment variables so that it works for everybody on the team, and in a way that works on Win7 too?
Thanks.
To make new teammates be able to code in VS2010 you have several options:
You don't need to change platform toolset to old one and rewrite your codebase. VS2010 developers can just install Windows 8 SDK, and use v110 toolset. To help them, configure "VC++ directories" in project properties as pointed in this article (change macro variables, which points to old Windows SDK, to explicit locations of new Windows SDK):
In “Executable Directories” replace $(WindowsSdkDir)binwith$(ProgramFiles)\Windows Kits\8.0\bin\x86`
In “Include Directories” add $(ProgramFiles)\Windows Kits\8.0\Include\um;$(ProgramFiles)\Windows Kits\8.0\Include\shared at
the beginning and remove $(WindowsSdkDir)include
In “Library Directories” replace $(WindowsSdkDir)lib with $(ProgramFiles)\Windows Kits\8.0\lib\win8\um\x86
In “Exclude Directories” replace $(WindowsSdkDir)include with $(ProgramFiles)\Windows
Kits\8.0\Include\um;$(ProgramFiles)\Windows Kits\8.0\Include\shared
When targeting x64, replace x86 with x64
If you really want to downgrade toolset from v110 to v100, then you will need to make use old standalone DirectX SDK. Before, Windows SDK and DirectX SDK was separate. They was merged since Windows 7 SDK. When merging, Microsoft decidede to remove some stuff and also renamed some files, for example, standalone SDK contains math in #include <xmmath.h>.
You can combine both: create multiple project/platform configurations and inmplement conditional compilation via #ifdef where VS2010 configuration will fail to find headers/compile. For example you can use C++11 features in VS2012 branch of code, but in VS2010 branch you use only C++03 features.
I would prefer first option, but it is up to you to decide.
P.S. As far as I remember, project files from VS2012 (.vcxproj) cannot be opened in VS2010 (it knows only .vcproj), so you cannot share it. You will probably want to install VS2010, make .vcproj and maintain both files. It can be pain when you change project options in one, and forget to change in other, so be careful. Also, consider to move all your team to single IDE, or at least single build system (for example, CMake).
Happy coding!
When I try to build a C# Console Application (and possibly others) it appears that TargetFrameworkDirectories is set incorrectly; in particular it omits the Facades directory.
Since I've been trying to diagnose the problem for a while, here is a list of possibly relevant facts.
The problem manifested itself when trying to build in Visual Studio 2012 a project that referenced the Reactive Extension libraries (managed using NuGet). The error (or warning) was warning MSB3267: The primary reference "System.Runtime", which is a framework assembly, could not be resolved in the currently targeted framework. ".NETFramework,Version=v4.5". The problem occurs during msbuild executing ResolveAssemblyReference
I can reproduce the error from command line with msbuild, which seems simpler
Other workstations do not exhibit the problem. Running msbuild with verbosity turned up on a good machine and on the bad machine turned up some differences in the log file
On a good machine TargetFrameworkDirectories (a parameter of ResolveAssemblyReference) is C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.5\,C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.5\Facades\ but on a bad machine it lacks the second entry (the Facades directory)
Scanning through the good and bad msbuild log files the following differences turn up:
Target AssignProjectConfiguration is skipped in the bad build, but runs in the good build
A number of targets like GetInstalledSDKLocations are skipped in the good build but are not mentioned in the bad build
The ResolveAssemblyReference task is passed Assemblies with Implicit=true in the good build but not in the bad build.
The ResolveAssemblyReference task is passed the task parameter TargetFrameworkDirectories with C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.5\ in the bad build, but the good build the Facades directory (see above) as a second item.
Since this is driven by C:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.Common.targets I diffed that file on the good and bad machine. They contained many differences. The first difference is the project element (line 17) which has an extra attribute TreatAsLocalProperty="OutDir" on the good machine. On the good machine the targets file contains more comments, such as <!-- VS10 without SP1 and without VS11 will not have VisualStudioVersion set, so do that here -->. Jumping to the AssignProjectConfiguration target, the good machine has Condition="'$(CurrentSolutionConfigurationContents)' != '' or '#(ProjectReference)'!=''" while the bad machine has Condition="'#(ProjectReference)'!=''" (which I assume explains why it was skipped).
One final thing I tried was repairing "Microsoft .NET Framework 4.5" and "Microsoft .NET Framework 4.5 Multi-Targeting Pack". It did not help.
Any advice would be appreciated, especially if I can avoid reinstalling Visual Studio 2012!
UPDATE: It seems that reinstalling .NET 4.5 followed by "merely" repairing VS2012 solved my problems. My best guess as to what caused this problem is that somehow my Microsoft.Common.targets was altered to an old version. I have no idea what could have altered the targets file.
As suggested by #leppie it was a .NET problem. For some reason repairing .NET did not seem to fix the problem. However reinstalling .NET 4.5 (followed by repairing VS2012) did seem to fix it.