During development of a teststep plugin the depending plugin(s) are referenced in .csproj :
The instrument plugin is developed in a separate VS Solution/Project and when built in Release mode the final TapPackage is copied to my local repo (O:\OpenTAP\GJC Packages) . This works fine and the plugin can be debugged and tested.
But when referenced in the TestStep Solution/Project the package can still fail to install. I find these problems hard to debug and the error info doesn’t help much.as seen here:
Any recommendations how to debug?
Also, a more VS related question: How do I “force” VS to re-load all package references? For example, after a plugin is modified but its version remains the same.
1 Like
In general, thinks works best when you specify the exact versions of things. So if you could specify the version of MyInstrumentPlugin and MyUtilities, that might help.
To debug, maybe you can try building with dotnet build -v normal. You can also set the log verbosity in Visual Studio settings.
I would do clean + rebuilds or ‘git clean’ to remove all files not checked into git.
2 Likes
Been struggling trying to understand how OpenTAP find other Packages (added to .csproj as OpenTapPackageReference) since this is not described in the doc.
I found a Package, with specified version, is looked-up in following order (correct me if I’m wrong):
- If already installed in project (in …/bin/Debug/Packages/) it is used
- If found in Package cache (/AppData/Local/OpenTAP/PackageCache/) this is installed
- If found in Packet repo(s) as specified in .csproj it is installed
- Error
This mean if a referenced Package is updated (re-built) but version remains the same you must manually delete the old package from bin/Debug/Packages/ and PackageCache so the new Package will be installed from repo (step 3 above).
(A workaround is of course to update version for every build, but this feels a bit overkill for minor modifications)
Does the OpenTapPackageReference element have additional attributes not documented in Developer Guide? The PackageManager has a checkbox for enable/disable package cache. Is this option also available as an attribute?
Perhaps a new attribute, like AlwaysInstall=“true”, could be added that bypass step 1 and 2 above?
Hi Goran,
There is no secret documentation about this feature. There is only the brief usage documentation which I assume you already found: Getting Started | OpenTAP
You can take a look at the source if you’re familiar with the .csproj format: opentap/OpenTap.targets at main · opentap/opentap · GitHub
The order you’re describing seems correct for current versions of OpenTAP, but this has not always been the order, and we make no guarantees that the order won’t change in the future.
In general, OpenTAP considers two packages identical if they have the same name and version. An AlwaysInstall attribute is also likely to cause you a headache since OpenTAP might decide to install the version in your package cache (which might be stale compared to the version you just updated)
We don’t really consume OpenTAP plugins in this way. In the vast majority of cases, we install plugins from the online repositories where package contents definitely do not change.
In the rare cases where I need to simultaneously develop two co-dependent plugins I usually end up copying DLLs and PDBs manually. I agree that this workflow is not optimal, and I understand your frustrations if this is a typical workflow for you.
It is also kind of difficult to add special behavior to OpenTapPackageReference in particular because it actually uses the image installer (specifically so it would have more predictable behavior).
I’m not sure what the best solution is in this scenario. You could try to write a custom .csproj <Target ... /> that manually force installs your package and always runs.
3 Likes
@alexander.larsen I know of a few others where the code changing but not the package version has created issues. I think this is a fairly common workflow for people developing plugins not in the repo.
I’m wondering, is there maybe a way we can just force the Package to have a unique name or version by either using a build number or a timestamp? It would then be much more obvious what package was being used in these situations.
1 Like
@brennen_direnzo if it’s a common workflow then I think it makes sense for us to support it. I know Rolf has also encountered this issue before.
We already write the package creation time into the package.xml file. In cases where there are multiple candidates available I think it would make sense to prefer the newest package.
Solving the issue involving OpenTapPackageReference will still require special care. Currently we only rerun the installation steps during a build if something was changed, but for this use case, we would need to revise this logic. In the past we didn’t have this check for whether the set of packages had changed, but this caused some undesirable behavior in Visual Studio.
3 Likes
Using the creation time sounds like a perfect solution.
And then install the newest found in bin/debug…, package cache and package repo(s)
Perhaps also add some additional documentation on how packages are found 
2 Likes
