I am doing some modifications on OpenCover and NUnit to suit my needs.
Briefly, I want to get coverage information even when shadow-copy is enabled in Nunit. However, OpenCover is unable to track an assembly when the pdb file is absent. When shadow-copy is enabled in NUnit, the assembly under test is copied to a shadow directory and OpenCover fails to find the corresponding pdf file.
At first, I thought that .Net Runtime just didn't copy pdb files to shadow directory. But After I investigated this problem further, I found out Runtime will copy pdb files but not the same time when assemblies are copied.
My understanding now is that Runtime will first copy assemblies to shadow directories. And then those assemblies will be loaded and Opencover is notified. OpenCover find out that there are no pdb files, so these assemblies are ignored. Sometime later, pdb files are copied, but OpenCover failed to notice this fact thus failed to track these assemblies.
So my question is what is the exact time that .Net Runtime copies pdb files to shadow directories? And is it possible that I modify OpenCover so that it will be able to track these shadow-copied assemblies?
However, OpenCover is unable to track an assembly when the pdb file is absent.
This is by design as instrumenting every assembly that is loaded without a PDB means instrumenting every IL operation rather than each sequence point, the information of which is in the PDB.
Sometime later, pdb files are copied, but OpenCover failed to notice this fact thus failed to track these assemblies.
If the PDB is copied later then its too late for OpenCover as the runtime has already loaded the assembly so OpenCover made its instrumentation decisions.
Now, OpenCover uses various locations to look for PDBs
it looks in the same folder as the assembly was loaded from
it looks in the folder set by -workingdir
it looks in its current directory
However, to support /noshadow I usually find the -mergebyhash option resolves this if not then I use #2 from the list above the easiest to use
Related
Is it possible include arbitrary files (in this case a .csv) from a TwinCAT project direct to the Boot directory of a PLC?
By using PATH_BOOTPATH in the file open/read FBs it is possible to load files from this directory in a convenient manner regardless of whether using a CE or Windows deployment, However deployment of files to this location seems to be the sticking point.
I know that a copy of the project code is included within the CurrentConfig<Project>.tpzip file, but this file is not easily accessible from code, or updateable.
I've found the 'Additional Files' section within the system configuration, but it makes little sense.
Adding a file from inside the project as a 'Relative' path doesn't seem to do anything
Adding a file from inside the project as an external path includes the file (via symbolic links?) in the 'CurrentConfig.tszip' file, which has the same issues as the .tpzip
Adding an external file as an external path again includes the file inside of the .tszip.
I'm willing to accept that this might not be possible, but it just feels odd that the PATH_BOOTPRJ and PATH_BOOTPATH roots are there and not accessing useful paths.
Deployment
To quote Beckhoff:
Deployment is used to set up commands that are to be executed during the installation and startup of an application.
The event types are essentially at what stage of the deployment process the command is performed, where the command can either be copying a file or execution of a script/program.
Haven't performed extensive testing but between absolute/relative pathing and execution this should solve nearly all issues with deployment configuration.
Is there anyway I can just call into a define such as LIBFOO_DIRCLEAN, and just do what was implemented in the define?
Inside HOST_LIBFOO_INSTALL_CMDS, I copy files to the target directory, and would like the 'make package-dirclean' to delete what was copied into the target directory. 'make clean', would obviously do this(any many more), but that is much more than I want to do.
I see the following buildroot variables. LIBFOO_EXTRACT_CMDS, LIBFOO_CONFIGURE_CMDS, LIBFOO_BUILD_CMDS, HOST_LIBFOO_INSTALL_CMDS, LIBFOO_INSTALL_TARGET_CMDS, etc.
make foo-dirclean is a simple tool that just deletes the package build directory. In most cases, when the list of files installed by a package does not change over time (only files content changes) you can simply rebuild the package and the target directory will be rebuilt correctly.
If you want you can implement your own foo-myclean step that implements your own logic. However you must understand deleting files in the target directory is not supported by Buildroot and thus you are on your own.
What is the proper way of delivering temporary build-time assets using nuget?
I am making a nuget package with a single file, which dependent projects require during the build phase. I would like the content of the file to be copied to obj\$(Configuration) folder inside a dependent project before proceeding with the rest of the build. Of course, the obj folder is temporary, so I would like my file to be copied there again as part of the next build if obj gets cleared out.
I tried contentFiles approach described here. This takes care of packaging my file inside nupkg file, but I was unable to set it up so that my file gets delivered (and re-delivered) to obj\$(Configuration).
You're looking for NuGet's MSBuild extensibility. Unfortunately it means you'll need to learn a bit about MSBuild if you don't already know it. I recommend running msbuild -bl or dotnet build -bl, which will create a msbuild.binlog file, which you can view with the msbuild structured log viewer.
One option is to have a target that creates the file in the intermediate output directory at an appropriate time (probably need to use BeforeTargets). You could use the Inputs and Outputs attributes to have msbuild do incremental build checks and skip copying when it doesn't need to, possibly making the build a little faster.
However, unless the file is has dynmanic content, copying the file is a waste. it's just going to be included as an item in another part of the build process. So, if it's static content, you could just create the relevant item in your targets file from your package's extracted directory, and then it's just as good as if it was copied to the intermediate output directory, without wasted time and duplicated disk space.
I have three files ImgProc.h, ImgProc.lib, and ImgProc.dll created by Matlab. I imported them to my VSC++ 2012 MFC project, but when I ran it, the error occurred. I did add the ImgProc.lib into the linker-> input->additional dependencies, Copied 3 files into project directory.
I could not add references. Because when I tried, it was empty like:
that
I really appreciate if someone could help me.
ImgProc.dll must be available at runtime in your application's directory. You need to manually copy this file to your output directories for both Debug and Release builds. Alternatively you can create a post-build step that does the copying. Having ImgProc.dll in your project directory is not enough - your project directory is not part of the Dynamic-Link Library Search Order.
We currently carry out development on a mapped drive. When I write nunit tests against a test assembly it will pick up the assembly, however does not recognise any of the tests.
If I move the solultion etc to a local drive and reference it again then everything works fine.
What I really woiuld like to know is why this is being caused, and how I can carry on using a network drive for development.
Per http://geekswithblogs.net/TimH/archive/2007/08/02/114340.aspx, NUnit apparently does not have appropriate permissions to access the assembly when on a network drive. The suggested fix is to add a post-build event to copy the assembly to a local temp directory and run NUnit off that copied assembly:
Within VS, open the project properties.
Go to the Build Events tab and enter the following 'Post-build event command line':
del /q c:\temp\nunit*.*
copy "$(TargetDir)." c:\temp\nunit
A potential issue you may have as a result of this change is related to the AppBase as per Unable to load <mytest> because it is not located under Appbase. The answer there is to update the Settings element within the .nunit file to include an app base of C:\Temp\NUnit then update the assembly element's path to remove any leading directory information.