I have a VSO release management definition in which I'm deploying a cloud service and then running some tests. The deployment executes without issues, but then the tests don't run, I recieve the following message in the logs:
Warning: No test is available in My DLL Path. Make sure that installed test discoverers & executors, platform & framework version settings are appropriate and try again.
Now, the strange thing is that this release is triggered by a build, which runs exactly the same set of tests and they all run happily.
I've included a runsettings file specifying the framework version (based on some SO posts I found from a year ago with a similar issue) but its made no difference. Been messing with this for nearly 2 days now with no progress. Any suggestions happily accepted!
Arrrrgh! So it turns out, if I deleted the whole project, created it again and added my tests again, it just works. Gremlins apparently!
Admins, if this needs to be deleted, go ahead
Related
I am working on a d365 unified interface sandbox environment on a development project.
This environment was setup recently as a clone of the production d365 instance.
Today I have been adding some plugins and finding a strange issue. I can get the plugin code on record create/update firing no problem (I have pre operation create/update and post operation create/update stages defined and the correct code gets hit for each).
But the C# plugin code does not recognise any of the pre or post images that I have added.
In code when we check IPluginExecutionContext.PostEntityImages it does not contain anything.
Any of the pre existing images that were there already when the environment was cloned are firing correctly. We have a process whereby we name all of our pre and post images the exact same for every entity and I know the ones I have created are named exactly as expected.
In this example I have created a Post Operation stage Update plugin on the OOB opportunity entity with a PreImage defined against it but the code just will not recognise it.
Anyone experienced this before?
TIA
Occasionally the sandbox service seems to fail picking up updates on a plugin assembly. In those cases updating the assembly with a different assembly version (build or revision number) can help.
If not, I would advise to simply remove the complete assembly and recreate it again.
If you do not have an automated deployment process in place, follow these steps:
Create a separate solution.
Add the assembly along with its step registrations and images to the solution.
Export the solution.
Remove the assembly using the plugin registration tool.
Import the solution again.
The problem
So I am running into an interesting issue. I have been tasked to change a query for a simple SSIS package in Visual Studio 2015, which is a thing I have done multiple times in the last 6 months.
After changing the package and deploying it (to an installation of SQL server 2016, without errors!) I noticed that the execution of the package (scheduled with SSMS) generates the same result as the pre-updated package, meaning the demanded changes hadn't taken effect. Of course, as test, I have executed the package directly from VS2015 and got the result I wanted.
Ever since I have been running tests and trying to find a solution. The problems seems to lie with the receiving side of the deployment proces.
What I have tried
Deleted the package from the existing project in SSMS and redeployed. Deployment again seemd to succeed but the package didn't show up, so I had to restore an old version of the project.
Deploy the package from multiple different computers with access to VS2015 and the source code. No change...
Deploy the package to a new (empty) SSMS project: package does not appear in the project. This leads me to believe that the old package is kept when I publish the new version to the existing project in SSMS.
Regenating/rebuilding the package in VS2015, frankly this was never necessary and probably doesn't do anything for an SSIS package, but it may help you get an idea of my skill level.
In the past we have had issues with the encryption level blocking the deployment of packages. I have verified these settings and found no issues.
I have verified if any updates have recently been installed to the database server, which does not seem to be the case.
I have (of course) tried to google the issue, which is tricky due to the lack of errors. I have found the following links, that describe the same/a similar issue, but their solutions haven't helped:
https://dba.stackexchange.com/questions/259672/ssis-package-not-being-deployed
Deployed SSIS Package not reflecting changes made to package
What is still left to try
Rebuild project from scratch to see if that version is deployable.
Unfortunately I don't have a lot of experience with this subject and no colleagues or contacts to ask for help.
Thanks in advance.
My workaround
After quite a bit of time attempting to solve the issue I have resorted to working around the problem, by manually importing the .ispac file into the database. While this is not the prettiest of solutions, at least it's a workable one. If anyone has any other idea's I'll gladly see them, but for now the issue isn't nearly as pressing as it was.
From your post. "Deleted the package from the existing project in SSMS and redeployed. Deployment again seemd to succeed but the package didn't show up".
Are you 100% sure you are deploying it to the same project on the same server on the database? Are you refreshing after you deploy?
Puzzling out how to implement VSTS for testing team.
Regarding the scenario where a manual test is run and a bug is created...
The bug gets prioritized and fixed at some later point.
How does the application indicate to the tester when they can run the test again because the bug has been fixed?
When you run the tests each time it has its own test run ID. That means they will have their own test results even if you run the same test case multiple times (They have different test run IDs).
Generally, once the bug is fixed and the fixed sources are integrated into the next release of the application, then you can run the test again to check if the bug is really fixed or not.
More information about the manual tests please see Run manual tests and FAQs for manual testing
I post this merely as a reference for others that might end up being in the same situation and since I spent almost 3 days trying to figure out the root cause of the problem, I thought it would be a good idea to post the solution here.
My situation was as follows:
I tried to build a deployment package for a .net application and got TypeLoadExceptions, FileNotFoundExceptions (regarding DLLs), Side-By-Side configuration errors, etc. once I tried to run it on a vanilla test machine.
[edit]: stackoverflow won't let me answer my own question within 8 hours of it being posted, the answer follows in ~8 hours ;)
The problem was that one of the dependency projects of my application was set to "Debug" build in the Visual Studio configuration manager, therefore the debug dll of the dependency ended up being used for release builds as well. On any development machine this was no problem after all since all debug runtimes were available.
On the vanilla test machine however only the release runtimes were present which caused so much trouble to me and gave me unmeaning exceptions that lead me to so many wrong directions via google, etc.
In my case it was SlimDX that was set to build a debug build in the VS configuration manager, even when doing release builds. Since SlimDX makes use of the VC runtimes I got the above problem, but this could happen with any .net assembly that uses the VC runtimes.
I hope this will eventually safe someone some hours ;)
I am running nightly builds using cc.net 1.4.2. I am also using nunit2.4.8. If I force the build manually it works fine but most of my nightly schduled builds fails saying testfixture setup failed. Is this some bug in nunit2.4.8 or something othert thing as I cant find out the reason
Is it the same cc.net project being forced that is scheduled to run nightly? If not, there may be a difference in how they are configured. If they are the same, I would suggest adding some logging to the test fixture setup code to see if you can track down the problem. Perhaps there is a nightly task running on the server (backup or virus scan perhaps) that is causing the issue. Another possibility is a task running on another server (taking a database offline for example.) I don't believe this is a bug in NUnit.