Does anyone know of a good resource for basic samples for both a NANT.Build file and a CCNet.Config file entry for nightly build on an ASP.net 4.0 application, having had a good look around online it appears that there's a lot of conjecture on how this should be done, but I'm looking for something sustainable.
I have projects that use .Net 2.0, .Net 3.5 and .Net 4.0 that all need to go through Cruise Control with Nant for nightly builds, so each needs to be individually configured, rather than just configuring Cruise Control for .Net 4.0, so am looking for the best practise here.
If you have visual studio installed on your build machine, here is the approach you can take. I used to use NANT and MSBUILD for pretty much everything, however I got tired of hacking it when we upgraded frameworks.
I have doing configuration management with Nant and CC.Net for a while now. In my experience I would not recommed using the Nant MSBuild task, instead the easiest way is creating and task, create a .bat file that the task executes. There are several reasons that would recommend using the command line Visual Studio, for one MSI packages are not easily build with Nant, even if you use contrib. Its just way easier and a lot faster this way.
.bat file with this
---------2.0 ------------- "C:\Program Files\Microsoft Visual Studio 8\Common7\IDE\devenv" C:\YourProject\YourSoultion.sln /Rebuild release
----------3.5-------------- "C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\devenv" C:\YourProject\YourSoultion.sln /Rebuild release
similar logic for 4.0
there is plenty of information about ccnet tasks here
http://ccnet.sourceforge.net/CCNET/Configuring%20the%20Server.html
ccnet config example
<tasks>
<nant>
<executable>C:\Nant\Nant0.86\bin\nant.exe</executable>
<baseDirectory>.</baseDirectory>
<buildFile>C:\NANT_SCRIPTS\build.xml</buildFile>
<targetList>
<target>DexWeb</target>
</targetList>
<buildTimeoutSeconds>2000</buildTimeoutSeconds>
</nant>
</tasks>
build.xml
<target name="DexWeb">
<exec program="C:\NANT_SCRIPTS\continous\dexbuild.bat" />
</target>
Related
I am attempting to move a solution from TFS 2012 to TFS 2018 SP2RC2 but I can't get the unit tests to run correctly. All projects have been re-targeted to 4.7.1 and are built as x86 platform. We have a testsettings file that supplies nothing but deployment items. I am using the new VSTest Platform Installer task (as directed by MS) and the VS Test Task. At the start of the test run I get the following message:
Test run will use DLL(s) built for framework .NETFramework,Version=v4.5 and platform X86. Following DLL(s) do not match framework/platform settings.
So all of the test are skipped as they target 4.7.1. Where is this 4.5 setting coming from? I cannot find it specified anywhere and can't figure out how to change it.
There is a /Framework: parameter that you can specify to VSTest.
In your case, you should specify /Framework:.NETFramework,Version=v4.7.1
See more at https://msdn.microsoft.com/en-us/library/jj155796.aspx?f=255&mspperror=-2147217396
To add this parameter in a Azure DepOps yaml pipeline, use the otherConsoleOptions argument
- task: VSTest#2
otherConsoleOptions: '/Framework:.NETFramework,Version=v4.7.1'
The fix I found for this in Visual Studio is way easier than I thought:
Exit all instances of VS
Open your project folder in Windows Explorer, find the .vs folder, delete it
Restart VS, the folder rebuilds itself, tests work again.
Apparently there are some settings that the NUnit plugin stashes in this folder and they are in binary so you can't edit them. This happened to me after I updated to NUnit3TestAdapter version 3.17.
I had trouble running a test project developed on another machine where no tests where able to be run using the MSTest test runner. In addition to message in your question I also got the messages:
Make sure that test discoverer & executors are registered and platform
& framework version settings are appropriate and try again.
Discover test finished: 0 found
In my case I resolved it by unloading and updating the .csproj file adding the following import directly under the root Project tag.
<Import Project="..\packages\MSTest.TestAdapter.1.3.2\build\net45\MSTest.TestAdapter.props" Condition="Exists('..\packages\MSTest.TestAdapter.1.3.2\build\net45\MSTest.TestAdapter.props')" />
Hope this answer will help save you some time.
I got this error using Visual Studio 2019 with NUnit 3.12.0:
Test run will use DLL(s) built for framework
.NETFramework,Version=v4.5 and platform X86. Following DLL(s) do not
match framework/platform settings.
Project.UnitTests.dll is built for Framework 4.5.2
and Platform AnyCPU.
Installed NUnit3TestAdapter 3.13.0 and then everything started working. Did not need to modify Framework version or CPU settings.
Had the exact same issue as Bill, working on legacy code in VS2019, nothing else had worked. I simply changed the Run Settings to use the Auto Detect.
In the menu go to Test -> Configure Run Settings -> Auto Detect runsettings File
For me skipping tests in local VS2022 run was related to testsettings file. I deleted .vs folder of my project then selected
Test ->Configure Run Settings -> Select Autodetect run settings file
After that I can debug unit tests
TLDR: If you use *.runsettings file for your test projects, try removing TargetFrameworkVersion node
I had similar problem but with .Net Core
Test run will use DLL(s) built for framework
.NETFramework,Version=v4.0 and platform X64. Following DLL(s) do not
match framework/platform settings. MyProject.Tests.dll is
built for Framework .NETCoreApp,Version=v3.1 and Platform AnyCPU.
Turns out there was another problem. For my other .NET Framework test projects I had defined *.runsettings file
And in this file I had
<?xml version="1.0" encoding="utf-8"?>
<RunSettings>
<!-- Parameters used by tests at runtime -->
<TestRunParameters>
<Parameter name="ConnectionString" value="Data Source=localhost;Initial Catalog=MyDatabase;Integrated Security=True" />
</TestRunParameters>
<RunConfiguration>
<!-- Framework35 | [Framework40] | Framework45 | FrameworkCore10-->
<TargetFrameworkVersion>Framework40</TargetFrameworkVersion>
</RunConfiguration>
</RunSettings>
Supported values for TargerFrameworkVersions based on https://learn.microsoft.com/en-us/visualstudio/test/configure-unit-tests-by-using-a-dot-runsettings-file?view=vs-2019
are:
FrameworkCore10 for .NET Core sources, FrameworkUap10 for UWP-based
sources, Framework45 for .NET Framework 4.5 and higher, Framework40
for .NET Framework 4.0, and Framework35 for .NET Framework 3.5.
But for Core 3.1, FrameworkCore10 doesnt work!
So I removed node TargetFrameworkVersion completely
I had the same problem in VS 2019 on a legacy project.
Restarting Visual Studio did not help, nor did build as Release then rebuild as Debug, nor did deleting the .vs folder. I did those things and still was unable to run tests, getting a message like the OP's during test detection each time. I mention these here for completeness.
I deleted the LocalTestRun.testrunconfig file and the *.vsmdi file from Solution Explorer, cleaned and rebuilt the solution, and the unit tests worked again.
I was running into the same issue with the Visual Studio Test Task version 2 in an Azure Devops 2019 pipeline after a .csproj test project was upgraded from .NetFramework 4.6.1 to .NetCore 3.1.
The fix for us was to be more specific when specifying the test files. The default of **\*test*.dll was finding several other assemblies with "test" in their names that didn't exist before the upgrade. Using an explicit **\<MyTestAssemblyName>.dll fixed the issue.
I've been extremely frustrated trying to deploy a C#/WPF application I've created that has some references to 3rd party DLLs. I created a folder in the project, called lib, where I placed all of these DLLs. In VS2012, I added the references by browsing to that folder, and selecting all the DLLs. Copy Local is set to true for all. Everything is fine when I build and run, but when I choose publish, and create a OneClick Installer, things aren't so smooth. During the publish wizard, I set it to install from disk, and set it to never check for updates. I take that folder, place it on a flash drive, plug it into another PC, run the setup, and it throws an Exception. I believe I know what is happening, but I cannot figure out how to package this in order to deploy it correctly.
One of my DLLs is a C# wrapper to a DLL that is designed for a C++ project. We'll say, Application requires DLL1 and DLL1 requires DLL2. DLL2 cannot be added as a reference in the project because is not a .NET DLL. DLL1 requires DLL2 to be in the same folder in order to pick it up. I'm using CefSharp which wraps the Chromium Embedded Framework.
I've tried placing the required DLLs for CefSharp.dll in the publish/Application Files directory, but it did not work. I noticed that all of the DLLs that are there from VS2012 have a .deploy extension on them, I even went and added that extension on to see if it was scanning for that to pick up, but it did not work either. This is my first time doing development and deployment for a Windows application and all of the tutorials on MSDN or blog posts I've read do not seem to cover this case, and I do not see any other options in the deployment manager to handle these types of cases.
If it helps, the Exception Code that is thrown is: CLR20r3
When I catch and display Exception, all of the info I am provided basically says CefSharp.dll or one of it's dependencies cannot be loaded. Which I've gotten before when DLL2 was not in the same folder as DLL1.
Can anyone provide help on how to deploy from VS2012 with a situation like this?
Thanks in advance!
Edit: Info Update
I was attempting to push a debug build version to a test machine without Visual Studio installed. When building for CefSharp or any other C++ Runtime DLL, it will look for all of the Debug versions of the DLL which are usually the same name, but with the letter 'd' added to the end. As mentioned below, the Debug version of the C++ Runtime is not redistributable. Not that you can't manually add those DLLs to your project and set them as Copy Always, but that's kind of a hack job. I started a new project from scratch, added all Release versions of the DLLs, built, and everything was fine.
I've been tearing my hair out trying to fix this very problem this morning and eventually found the solution. It seems you already know which DLLs etc. you need for CefSharp to work but I thought I would run through this in case anyone else is having the same problem. I have a C# WPF application and I'm using CefSharp as the web view. I'm using CefSharp v1 because I need the JavaScript -> C# bridge they provide which isn't yet implemented in v3. Here are the rough steps I went through in setting up the project (I'm using VS2013 but this will probably work in VS2012).
Installing CefSharp
Install CefSharp.Wpf through NuGet (I'm using v1.25.7)
That should put the relevant files in $(SolutionDir)packages\CefSharp.Wpf.1.25.7\cef
Configuring Build
To get the CefSharp DLLs to copy to our build folders, right-click on your project, select Properties -> Build Events and enter the following in the "Post-build event command line":
xcopy "$(SolutionDir)packages\CefSharp.Wpf.1.25.7\cef*" "$(TargetDir)" /s /y /i
That should now copy all of the required DLLs from the cef folder as well as the devtools_resources.pak file and the locales folder plus its contents. I require them in my project as I need the chromium dev tools.
Double-check your project references contain CefSharp and CefSharp.Wpf. That should have been taken care of by NuGet.
Taking care of Visual C++ 2012 Runtime Files
I didn't want the user to have to download the whole Visual C++ 2012 Runtime Files as part of the deployment so through Visual Studio, add the folder Lib\Microsoft.VC110.CRT and add the 3 DLLs (msvcp110.dll, msvcr110.dll, vccorlib110.dll) from the following folder on your machine to the folder you just created in your project:
C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\redist\x86\Microsoft.VC110.CRT
Select the 3 DLL files in Visual Studio, right-click -> properties. Make sure Build Action is set to "None" and Copy to Output Directory is set to "Do not copy". Now you need to add another post-build event to make sure these are copied properly (i.e. copied to the root so they sit alongside the CEF dlls and your project exe) for debug.
Right-click on your project, select Properties -> Build Events and enter the following in the "Post-build event command line" just after your other xcopy command for CEF:
xcopy "$(ProjectDir)Lib\Microsoft.VC110.CRT*.*" "$(TargetDir)" /s /y /i
At this point, everything should be building. To publish the app with ClickOnce, I need it to push all of the CEF DLLs out as well as ensuring the files/folders required for chromium dev tools are present. If you don't need the dev tools or all of the DLLs then you can tweak this accordingly.
Ensuring CEF and C++ runtime files are deployed with ClickOnce
Right click your project in Visual Studio and select "unload project".
Right click and select to edit the csproj file.
Before the closing </Project> tag add this
<ItemGroup>
<Content Include="$(SolutionDir)packages\CefSharp.Wpf.1.25.7\cef\**\*">
<Link>%(RecursiveDir)%(Filename)%(Extension)</Link>
<Visible>false</Visible>
</Content>
</ItemGroup>
<ItemGroup>
<Content Include="$(ProjectDir)Lib\Microsoft.VC110.CRT\**\*">
<Link>%(RecursiveDir)%(Filename)%(Extension)</Link>
<Visible>false</Visible>
</Content>
</ItemGroup>
That will add everything from the cef folder into the project and make sure the C++ binaries are copied to the root of the project on deployment. In my case for CEF, I'm using the \**\* syntax at the end of the Include and %(RecursiveDir) to ensure all of the files are copied as well as the locales folder with its contents and structure preserved. Having set <Visible>false</Visible> you won't see the items in the solution explorer.
Relax
Now if you publish your app, it should copy over all of the required files and folders.
You could try this which solved a similar issue for me:
Add the DLL's that are not .NET libraries to the solution as files:
Right click project > Add > Existing Item
Then set their build action to Content and "Copy to output directory" to "Copy Always".
That way the libraries will be included in the output directory.
Since you already tried manually adding the suspect dll and it still does not work, the next thing I would do is run fusion and see what it really is complaining about, in other words what exactly is the dependency that can not be loaded. Here is a good tutorial on how to hunt down these types of errors:
Back to Basics: Using Fusion Log Viewer to Debug Obscure Loader Errors
Maybe you can work it out from the https://github.com/Code52/DownmarkerWPF sources?
They have at least a working ClickOnce installer for their app embedding CefSharp. I know because that's the way it got installed on my machine!
update just saw in comments that it's the VC Redist that you say you are missing then Distributing the Visual C++ Runtime Libraries (MSVCRT) seems relevant.
Also I seem to remember something vaguely about that for "VCRedist reasons" you are not supposed to distribute debug versions of your application. Can't you just switch from a Debug to a Release version? With this I think you can either bundle the needed VCRedist files as suggested in the CefSharp FAQ or add VCRedist as a prerequisite in your installer. DownmarkerWPF does it with their WIX installer setup which you can find on a branch in their GitHub repo. Something similar is AFAIK possible with the VStudio bundled installer if that's what you use.
Thanks to Barrie's answer to this, it helped me greatly. I'm using his answer below, but updating it to work for the latest CEF using Visual Studio 2015.
NOTE: I am only building/targeting the x86 platform. You may need to change or include x64 in the copy commands below to suit your needs.
Installing CefSharp
Install CefSharp.Wpf through NuGet (I'm using v51.0.0)
NuGet Library After Install
That should put the relevant files in
$(SolutionDir)packages\CefSharp.Wpf.51.0.0\CefSharp (CefSharp.Wpf)
$(SolutionDir)packages\CefSharp.Common.51.0.0\CefSharp (CefSharp.Common)
$(SolutionDir)packages\cef.redist.x86.3.2704.1432\CEF (Cef x86 redist)
$(SolutionDir)packages\cef.redist.x64.3.2704.1432\CEF (Cef x64 redist)
Configuring Build
To get the CefSharp DLLs to copy to our build folders... I don't believe this is necessary anymore with the later versions of CefSharp. I found that I didn't need any of the "Post-build event command-line" xcopy stuff to get Click-Once to ship it out. (And yes, DevTools works too!)
Taking care of Visual C++ 2012 Runtime Files
(Switched to VCR 2013) I didn't want the user to have to download the whole Visual C++ 2013 Runtime Files as part of the deployment, so through Visual Studio, add the folder lib\Microsoft.VC120.CRT and add the 3 DLLs (msvcp110.dll, msvcr110.dll, vccorlib110.dll) from the following folder on your machine to the folder you just created in your project:
C:\Windows\SysWOW64
(Didn't see them in C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\redist)
At this point, everything should be building. To publish the app with ClickOnce, we need it to push all of the CEF DLLs. You can tweak this accordingly...
Ensuring CEF and C++ runtime files are deployed with ClickOnce
Right click your project in Visual Studio and select "unload project".
Right click and select to edit the csproj file.
Before the closing tag add the following:
<!-- BEGIN: CUSTOM ITEM GROUP INCLUDES INTO THE PROJECT (SO CLICK-ONCE PUBLISHES THEM) -->
<ItemGroup>
<Content Include="$(SolutionDir)packages\cef.redist.x86.3.2704.1432\CEF\**\*" Exclude="$(SolutionDir)packages\cef.redist.x86.3.2704.1432\CEF\x86\**\*;$(SolutionDir)packages\cef.redist.x86.3.2704.1432\CEF\locales\**\*.pak">
<Link>%(RecursiveDir)%(Filename)%(Extension)</Link>
<Visible>false</Visible>
</Content>
</ItemGroup>
<ItemGroup>
<Content Include="$(SolutionDir)packages\cef.redist.x86.3.2704.1432\CEF\**\en-GB.*;$(SolutionDir)packages\cef.redist.x86.3.2704.1432\CEF\**\en-US.*">
<Link>%(RecursiveDir)%(Filename)%(Extension)</Link>
<Visible>false</Visible>
</Content>
</ItemGroup>
<ItemGroup>
<Content Include="$(SolutionDir)packages\cef.redist.x86.3.2704.1432\CEF\x86\**\*">
<Link>%(RecursiveDir)%(Filename)%(Extension)</Link>
<Visible>false</Visible>
</Content>
</ItemGroup>
<ItemGroup>
<Content Include="$(SolutionDir)packages\CefSharp.Common.51.0.0\CefSharp\x86\**\CefSharp.BrowserSubprocess.*">
<Link>%(RecursiveDir)%(Filename)%(Extension)</Link>
<Visible>false</Visible>
</Content>
</ItemGroup>
<ItemGroup>
<Content Include="$(ProjectDir)lib\Microsoft.VC120.CRT\**\*">
<Link>%(Filename)%(Extension)</Link>
<Visible>false</Visible>
</Content>
</ItemGroup>
<!-- END: CUSTOM ITEM GROUP INCLUDES INTO THE PROJECT (SO CLICK-ONCE PUBLISHES THEM) -->
That will add everything from the cef folder into the project and make sure the C++ binaries are copied to the root of the project on deployment. Having set false you won't see the items in the solution explorer.
REMEMBER: I am only building/targeting the x86 platform. You may need to change or include x64 in the copy commands below to suit your needs.
Publish
Now if you publish your app, it should copy over all of the required files and folders.
(EXTRA INFO) Supporting Older Operating Systems Info Below
If you need to use CefSharp for older machines (XP & Vista), simply
install CefSharp.Wpf through NuGet using the older v47.0.0 version and change your .NET targeting to .NET 4.0 Client Profile.
Chromium ended support for XP and Vista in April 2016, CefSharp version 47 (or there abouts) still had support for it.
Another note on a problem and fix for XP:
There is a Chromium issue for XP deployments. Below is the article describing the fix followed by steps to deploy fix for JBCB.
Here's the link to the article:
https://bitbucket.org/chromiumembedded/cef/issues/1787
...in it you'll see a reference to download a "dbghelp.dll". Download and extract.
YOU CAN TAKE A POST-INSTALL APPROACH LIKE BELOW OR CHOOSE TO INCLUDE THE DLL ALONG WITH YOUR OTHER PUBLISHED FILES. I'M CHOOSING NOT TO DEPLOY THE EXTRA DLL AND ONLY DEPLOY ON XP MACHINES (WE ONLY HAVE FEW) MANUALLY.
Take these steps to fix deployment on an XP machine:
Install the CefSharp Browser on the XP machine (via Click-Once)
Copy the "dbghelp.dll"
Paste it in the local install directory on the XP machine (per the instructions in previous link: along side the "libcef.dll" file).
NOTE: For click-once installs, will be in a sub-folder under this location:
C:\Documents and Settings\<UserName>\Local Settings\Apps\2.0\<auto-gen ostificated ID>
Read very carefully the official list of CefSharp dependencies - there are a lot of them! You need to get them all into the ClickOnce bin folder somehow.
Here is how I solved it:
Before deploying, install the latest version of Visual C++ Redistributable. on each PC you are deploying to (using group policy or just manually).
Start with a blank test project.
Add project references to CefSharp, CefSharp.Core, etc.
Add each dependency into a single folder in the project directory to keep them organised (Files\CefSharp\).
Ensure all files are configured with Build Action: Content, and Copy to Output Dir: Copy always.
Make a function Initalise_CefSharpFiles() to copy the files/folders into the bin root folder (where CefSharp looks for them). For example, copy from: Bin\Files\CefSharp\* to: Bin\*.
And finally at run time, call Initalise_CefSharpFiles() once after the app loads, and before initialising CefSharp's settings.
I am have built an MSBuild project that has
the main .proj file with several Targets inside,
several .targets files
and several .rsp response files to run this project in several ways. Such as
Build, Clean/Build/Deploy, Clean/Build/Test/Deploy.. You get the idea.
What I now want to do is take this MSBuild and run it in TFS scheduler after I pull the source code. So the workflow should be
1. Pull the source code in TFS
2. Run MSBuild project in the scheduler so I might set up tasks to run hourly and nightly.
The MSBuild will take care of Deploying to IIS, unless someone has a more efficient way of deploying after an hourly build.
How can I accomplish this in TFS?
Thank you
You can use the Team Explorer UI in Visual Studio to define a "scheduled" build definition.
http://visualstudiomagazine.com/articles/2012/04/11/creating-a-build-definition-in-tfs.aspx
If you want to take this to the next level, research "continuous integration" which is also a built in capability.
I am new to Cruise-control.Net and Automatic build concepts. Could you please suggest me how to use cruise control.net to perform automatic build for a sample asp.net 4.0 build application. Please let me know what are the prerequisites in order to use Cruise-control.net
If you are using visual studio, it will give you a project file (.csproj or. vbproj).
You can use the msbuild task in cruise control to build this project which will build the website.
If you need to you can execute aspnet_compiler to compile/validate the other resources in your website, such as in line code in an aspx Page, or. Cshtml razor views.
There should be no other prerequisites for cruise control to do this.
A blog post I wrote a while ago is just what you're looking for. Continuous Integration with Cruise Control .NET
This method doesn't require you to have Visual Studio installed on your build machine. You will need to have .NET 4.0 installed on the build server, though.
How do I run stylecop against an iis based webproject on a buildserver?
Buildserver runs in continuous integration and I would like this automated.
With a library I can add a few lines to the .csproj and its done. I believe it to be a website application project.
Is it a web application project or a web site in Visual Studio? With the former option, it is compiled into an assembly, so you could always run StyleCop from the build scripts when building the assembly.
Alternatively you could run StyleCop as a plugin from within VisualStudio, but you're probably asking for automation here. It all depends on your build process, I think. There are various build configurations, so please elaborate a bit more on what are you actually doing on this build server. Continuous integration?
Not possible with the project type, projects need to be converted.