I have a home grown project (https://github.com/andybantly/MFC-Fractal) that I have been working on since the Visual Studio 2005/2008 days. I just recently put it in Git. Its home is on CodeProject.
I am not sure when this started (maybe 10 years ago...) but when I migrated my application to the latest version of Visual Studio, new/odd behavior injected itself into the code generation step. The IDE has somehow decided that when I build the source that I really wanted to build and run the source. This is somewhat annoying, especially during a batch rebuild all.
I am looking for helpful suggestions on configuring the IDE to prevent this behavior. It never used to do this out of the box.
Is it a show stopper? Absolutely not. Is it annoying? Depends on the side of bed I woke up on.
Related
We are attempting to upgrade our rather old TFS environment from TFS2008 to TFS2015. The upgrade of the server and database is not a problem and is fine.
The issue is our build machine. This is still a Windows 2003 Server that is running Visual Studio 2010 and VB6. We still have a need to use this build machine to build legacy VB6 projects. We have installed the TFS2010 XAML build controller on this server and successfully connected it to our test TFS2015 server. However when we try to run a Xaml build, (any Xaml build regardless of whether it builds VB6 or .NET) we get the following error message almost straight away.
TF900560: Could not start build: Cannot set unknown member 'Microsoft.TeamFoundation.Build.Workflow.Activities.TfsBuild.TargetsNotLogged'.
The XAML build are using the 'UpgradeTemplate.xaml' template and using the TFSBuild.proj we used under Visual Studio 2010.
We have a also set up a TFS2015 build controller on another (Server 2012) machine and that successfully starts the build process. However, our VB6 projects use a lot of third party components that will not install on Server 2012 so we can't use that.
Has anyone ever set up this kind of arrangement before? Is there anything we are missing or are doomed in this scenario? Obviously, we'd like to move away from VB6 apps, but that is not possible in the medium term.
I just created a new empty universal app (windows 10) and checked it in on my visual studio online project.
The configured build is constantly failing on following error...
The imported project "C:\Program Files
(x86)\MSBuild\Microsoft\WindowsXaml\v14.0\8.2\Microsoft.Windows.UI.Xaml.CSharp.targets"
was not found. Confirm that the path in the declaration is
correct, and that the file exists on disk.
I set build configurations to use VS2015 but without any luck.
I keep thinking there's a simple configuration I'm missing here... but can it also be that it's not yet supported?
The project itself is just the standard template from Visual Studio.
I'm having a similar issue running with MSBuild 8.2 target missing under VS2013 Update 5 under Windows 10 TH1. Except my target is Microsoft.Windows.UI.Xaml.Cpp.targets. So not necessarily an issue with Visual Studio but rather the substitution for $(TargetPlatformVersion) in the targets definition:
<Import Project="$(TargetPlatformVersion)\Microsoft.Windows.UI.Xaml.Cpp.targets" />
I'm building a project from Microsoft (https://github.com/Microsoft/winsdkfb), so I don't think this is your problem (meaning you've not done anything incorrect).
I know this isn't an answer, but I suspect we're caught in a gap in the Windows 10 SDK & Tools. Those aren't scheduled to be complete and available until 29 July even though VS2015 has RTM'd. I tried to track down something in the VS2015 release notes without luck.
Just inform the solution I found on this thread.
At the time of writing, it appeared that VSTO serves were not yet updated with
the Windows 10 SDK.
The only way back then to make it run was by creating your own Build VM (through Windows Azure) and link it to your VSTO builds.
I posted the thread and got the answer on the MSDN TFS forum.
I have not tried it right now, but since Windows 10 is officially released now, I guess it may work out of the box.
We now support building Universal Windows Platform (UWP) projects on the hosted build service.
I have some big problems with my new environment and I think related to managed vs native code.
After my harddrive crashed I installed Visual Studio 2010 on a Windows 8 (which is new to me) and used backups of my Visual Basic .NET code files.
My issue is that the standalone debug executable crashes (with error code 0xc0000409) without me being able to see my source code ('No native symbols in symbol file'). It turns out it is running in native mode (Process: [140] myApp.exe: Native), which I did not think Visual Basic ever did.
When debugging from the GUI I have symbols and, to my surprise, it finds two MyApp.exe in the modules list, one native and one managed.
Some more details, I use ODBC, build for x86, and use .NET 4 client profile. As my project settings are similar or identical with my pre-crash setup I think the configuration problem is in my environment/OS, but I cannot find it after days of searching.
Can I make my standalone executable file execute in managed mode so I can debug it with symbols when it crashes? I have been able to do this for years with my old setup.
Any tips or hints would be very much appreciated.
I have written dozens of custom code analysis rules. The rules were developed targeting Visual Studio 2010. As required, the assembly has a reference to version 10.0 of FxCopSdk, Microsoft.Cci, and Microsoft.VisualStudio.CodeAnalysis. They run correctly in Visual Studio 2010 and build properly in TFS 2010.
I'd like to migrate to Visual Studio 2012. When I run the custom rules on an existing solution using VS 2012, however, I get CA0062 errors. The root cause is a CA0053 error loading the custom rules assembly. I understand that these references to the three assemblies need to be updated to version 11 for Visual Studio 2012. This can be done using version redirects in config files. I can get this to work locally by redirecting the Visual Studio 2012 IDE and FxCopCmd binaries, but am running into trouble when checking code into TFS 2010.
There are two apparent solutions we have considered, but neither is very palatable. The first is to require each developer to redirect locally, and then modify the TFS build agents to redirect as well. The second is to maintain two branches of the custom code analysis rules, one targeting version 10 (VS2010) and the other targeting version 11 (VS2012).
Is there a better way to do this, or do we need to all upgrade to TFS 2012 and Visual Studio 2012 simultaneously?
You can try to manually edit the project file and write two include blocks (one for VS2010 and one for VS2012), then define conditions to use the correct one. You only have to somehow determine if You want to build for VS2010 or VS2012 in msbuild.
Between your approaches and the one proposed by ZFE, you pretty much have all the potential candidates. Given the choices, I would strongly recommend branching since there is no official SDK for FxCop with backward-compatibility guarantees.
If you're lucky, you won't hit any behavioural or API surface changes that affect your rules, and the only difference between your two branches will be the references, so any merges will be trivial. However, any time investment you make in an alternate approach now will be lost if you need to branch later, and the likelihood of eventually needing to branch is non-negligeable.
How do I disable the background compiler for Visual Basic in Visual Studio 2008?
For my sins, I have to work on a large VB.NET project and it often locks up for 20 seconds at a time whilst doing the very helpful background compilation which is extremely frustrating.
I'd rather work blind between compiles and be able to do some work.
No there is no way to disable the background compiler.
Have you installed Visual Studio 2008 SP1. There were several bugs we fixed in the RTM version of VS 2008 which can cause the IDE to hang under certain circumstances.
We take issues with the background compiler very seriously. If you can give us a repro of the problem it will definitely be investigated. If you can produce such a repro or even send us a memory dump when the IDE is locked please file a bug on Connect: https://connect.microsoft.com/VisualStudio
A couple of other steps you can take. Do you have any Add-ins installed in VS? If so try uninstalling them 1 at a time. I've seen several cases where 3rd party add-ins caused lock ups in the IDE which were completely unrelated to the C#/VB framework.