I have been signed a task to set up CruiseControl.NET for our project. Everything went fine until I stomped on the fact that we were using Async CTP. My questions are following:
Are there any options for calling Async CTP build machine other than through Visual Studio? (Do the preprocessing manually without using VS.)
How to force CruiseControl.NET to build a project with Async CTP?
The trick that worked for me was to take the msbuild from my pc where I had VS with async ctp installed and replace the msbuild on the build machine at the build server.
I'm not familiar with Cruise Control .NET, but I'm familiar with how the Async CTP works.
The CTP includes an CTP-capable compiler. You should be able to install the CTP on your build machine, which will allow for it to compile Async .NET code.
If the CTP installer requires Visual Studio, you should be able to install VS, then the CTP, and then uninstall VS while still leaving a CTP-capable compiler on your machine.
This is similar to how I would expect someone to use the CTP in conjunection with compile-on-demand scenarios for ASP.NET.
I use another build server tool, TeamCity, but since it all comes down to MSBuild, I think it should work the same.
I had the same doubts about the compatibility with the Async CTP, since it adds keywords to .NET itself, but after trying it, it seems that all you need to do is reference the AsyncCtpLibrary.dll in your project, and make sure that the DLL gets to your build server. I suggest including it in your version control system, ex. Subversion, so the reference is relative to your project root and will automatically be at the right place on your build server.
This way you don't have to "trick" your computer to install the full package.
Related
When I try to run (debug) functions in Visual Studio 2017 on one of our machines, the following dialog pops up!
The target framework for the project is <TargetFramework>net461</TargetFramework>. For some reasons I am not able to install .NET 4.7.1 and now I am completely lost. I am sure it was functioning in the past on the same machine. Probably one of the updates caused it.
Any idea how to resolve it?
This is because the latest version of the Azure Functions Tools for Visual Studio now requires .NET Framework 4.7.1 (as of February 2018).
Note that this does not impact the target framework that you compile against - only the target framework your code runs against. Similarly, when you run in Azure, you can expect the .NET runtime version to be .NET Framework 4.7.1 (at the time of writing).
I tried implementing the solution mentioned in comment. However, it didn't work for me. However, reverting the Azure Functions Tools to previous version worked. Thanks Chris for pointing that it was Azure Tools and not any packages that caused it.
If anyone else should come across this.
For me, the issue was the actual func.exe config that needed to be upgraded.
Navigate to:
C:\Users[USER]\AppData\Local\AzureFunctionsTools\Releases[VERSION]\cli
.. my version was 1.4.0
Modify the func.exe.config to match the .net version installed
.. it was 4.7.1
I am trying to update from VS2013->VS2015, and to do that I need to rebuild my boost library files using VS2015. I grabbed the latest boost (1.58). By default boost is trying to build with VS2013. I tried to invoke bjam with toolset=msvc-14.0 but this did not work, as it keeps saying:
'cl' is not a recognized as an internal or external command
I guess it doesn't know where VS2015 is located? Does anyone know what I need to change to get boost to build with VS2015?
BlueGo is a tool which builds Boost using Visual Studio 2010/12/13/15. You just have to start the application, select your configuration and hit the Build button- everything else works automatically. The application downloads the library, extracts it and builds it. Can be downloaded from here.
Screenshot of BlueGo:
You also need to install Common Tools for Visual C++ 2015 as described here.
Prebuild boost libraries for VS2015 can be found here. Those seem to be very carefully maintained.
I recently acquired XMLSpy 2013 and was naturally excited to see there was a Visual Studio integration package. I'm running VS 2012, but nowhere on Altova's download page does it mention compatibility requirements/limitations.
So I followed the steps on the Altova download site (basically just run the package and you're done). Nothing changed in VS. So I decided to download the 1326 page PDF manual for XMLSpy to see if there was some extra help in there:
http://www.altova.com/documents/XMLSpyPro.pdf
On page 490, it mentions going into your VS/Common7/IDE directory and running devenv.exe /setup which I did. After that, again, nothing changed.
Has anyone had any success with getting this integration package to work? I can find almost no information by searching the web.
I actually created a support ticket with Altova for the issue as well, but thought I'd try here for some first hand experiences.
Whelp, Altova support responded to my ticket. The answer is, since Visual Studio is a 32-bit only application, XMLSpy integration will not work when running the 64-bit version of XMLSpy/XMLSpy integration package.
This is despite the fact that both a 64-bit version of XMLSpy AND a 64-bit version of the Visual Studio Integration package exist side-by-side on the download page (as of writing this answer). I have a feeling that it might only exist for the Eclipse integration.
http://www.altova.com/download/xmlspy.html
Once I installed the 32-bit versions of XMLSpy/Integration package, it all worked as promised. I hope this helps someone in the future at least.
We're planning moving from Visual Studio 2005 to Visual Studio 2012 (Visual-C++-11).
(We would very much like to skip 2010 if we can help it, since the newer version is already there and offers a better C++ experience.)
But we've hit a little roadblock:
Our build servers still run Windows 2003r2 (all inside dedicated virtual machines), and due to messy tool support/issues, we're in no position to upgrade the build servers to a newer OS.
Developers mostly have switched to Windows7 by now, so moving the remaining Windows XP developer boxes shouldn't pose a problem.
Since VS2012 only runs on Win7 we are wondering whether we can leverage it's tools (C++ compiler, C#) and still do a full equivalent build on the W2k3 build server - after all, we don't really need a VS GUI there, just build C++ and C# projects from VS2012.
What are our options?
Will the SDK (7.1? 8?) compilers + msbuild command line get me anywhere?
In Project Property Pages, there an option "Platform Toolset" that allow you to choose compatibility of your project. So, you can work in VS2012, but built it with "VS2008 compiler"
Here is what we do:
Use CMake
CMake allows you to create build systems for your operating system. Thus we are able to use the same code within VS2005, VS2010 and Eclipse, XCode etc.
You could do something similar: Install VS2005 on your old machines and let CMake create the projects for you from the sources. On your newer machines you can use CMake to generate VS2012 Solutions (I don't know if they have 2012 support yet, because we don't use 2012 yet too).
A big pro here is: If you plan to migrate to any other IDE or even Linux you just can re-run CMake and get your source code within these environment easily compilable.
A big con: You have to start reading about CMake and create CMakeLists.txt for all your projects (might be a lot of work depending on the amount of projects, amount of source code files within each project, specific compiler options, linker options etc.)
Our build servers still run Windows 2003r2 (all inside dedicated
virtual machines), and due to messy tool support/issues, we're in no
position to upgrade the build servers to a newer OS.
Well. Not much came out of this question. We recently re-evaluated this issue, and I see two options (I haven't tried any yet):
Just do a full VS installation on a supported OS (Win7), zip up the whole VS+WinSDK directories (as well as the neccesary runtme DLLs that live somewhere under %WINDR%), and try if you can get that thing working on an XP based OS. Might work. Not a great idea if you ask me.
Split up the build process to distribute the build across several OS, so that we can work with tools that are only supported on one of them. -- This actually sounds more complicated than it'll be. We already run our build spread over several Jenkins jobs, so I should be able to get that to work. (And all build nodes are already VMs anyway, so adding more VMs isn't that much of an issue.)
So I've downloaded VS2012 RTM and upgraded my Coded UI test projects to the VS2012 versions.
The reason I have done this is because I was having issues with VS2010 Coded UI tools due to partial support of IE9.
So I ran the tests from my developer machine both locally and remotely (making use of the new Visual Studio agent tools), and the tests worked successfully. Presumably, the reason my tests now work is that VS2012 upgraded them so that they now work with IE9, right?
So - this is my problem. I want to automate these tests, by launching them from our build machine - but our build machine still runs on VS2010, and for the time-being this is not going to change.
So I checked in my new VS2012 Coded UI test solution into TFS and queued a new build - so the build machine built my solution. And the build was successful. All good there.
So, next I created a new test case in Microsoft Test Manager and associated with the ordered test list in my new solution. Then I launched the tests (using the existing VS2010 test controller) on my remote test environment (which has the existing VS2010 test agent tools).
But the tests failed - the same issues that affected my tests with the VS2010 Coded UI tests (due to lack of full support for IE9)
Why did they fail?
Do I need the new VS 2012 agent tools for my test controller and agents? Must I build my solution in VS2012?
Ideally, I don't want to have to install VS2012 RTM on my build machine - I want to do the minimum possible to get my tests working and automating.
Is there a way around this?
Your coded ui tests reference assemblies that come with VS installation or your agent's installation (the assemblies defininf the WpfControl, Mouse, Keyboard, Playback and other classes).
So if you run it on a build/test machine with older versions of the dll's the same issues are going to stay, the tests will not start using the newer fixed assemblies thatt were shipped with VS2012.
As a temporary workaround you can check what dll's you reference and make sure that the build process puts them in the same directory with your tests assembly. That way the lookup for them will find the in the current directory without using the /path and finding them in the VS installation directory.