I have a project that is written in MSTest. I have 3 machines that has VS2012 Ultimate Update 4 installed. But with this project, on one of my 3 machines, the DeploymentItem are not copied to the output folder which in turn causes unit test failure. The other two machines are fine with the same project. I am using TFS as source control system. Can someone help me fix this issue?
Update: I have given up, this seems to be an issue of VS2012 installation itself cause the same project can run tests fine on other machines
Do you have a different test project on that machine that points to the same output folder?
According to this thread, one of the projects could fail to output in that case.
It could be that you excluded the extra project on the working machines, or that the order in which the projects are built and deployed is different. Are there any other differences (like number of processor cores) between the machines?
Another cause could be differences in user rights on the different machines (depending on the destination directory you are deploying to). Try starting Visual studio on the failing machine by right-clicking on the icon and choosing run as administrator. Does that make any difference?
Since it is working on your other machines, I guess the copy to output directory properties are already true.
This is a wired one and I encountered a similar issue most recently where the build and output to folder was successful in few machines while it was failing in others. My web project was referencing assemblies from the GAC and a folder located in the relative path inside the solution.
Machines where the output was failing, I was receiving this error in the output something like --> Can't locate or access assemblies in the path..
I resolved the issue by
Removing all the assemblies that were referenced form the relative path
(optional) Manually removed the debug and release folders in both bin and obj folders for all projects. (Probably a clean solution option in the build menu will work as well here, but I avoid taking risk and wanted to be sure)
Added back the assemblies from the local path.
Re-build the project
Run the test project and everything was working fine in all machines.
Hope this helps !!!
It turns out it's my own fault. I didn't set the Test settings in the "Test -> Test Settings" menu. But how could I know? VS2012 on my other machines are all configured automatically. For some reason, that particular machine didn't. So there you have it, the answer to the question. It's a simple one. But when you don't know, it's utterly hard.
Related
I have an xamarin mobile app with 3 projects. Shared, Android and iOS.
All 3 build perfectly fine locally but fail on Azure Dev ops pipeline.
iOS and Android only have 2 xmal views that are platform specific. The rest are located in Shared.
For both of the xmal views, all the errors are coming from the code behind cs files complaining that something doesn't exist in the current context. There are around 80 errors like the one below. The errors are identical on both platform builds.
Example error from Droid build:
Droid\Views(Filename).xaml.cs(26,13): error CS0103: The name 'InitializeComponent' does not exist in the current context
This build hasn't run for a while, around 8 months. It used to work fine and none of the views xmal/cs code has changed. I'm assuming a version is now misconfigured somewhere.
Both builds run on VS 2022 pipelines.
Both builds restore okay.
I have tried (Mostly suggestions from similar posts)
Adding restore argurment to the Build step.
Checking name spaces match
Adding a small change (whitespace) to the 2 xmal pages to force a change.
Removing the shared project reference and re-adding it.
I would be grateful for any suggestions or ideas.
Thanks in advance.
In past experience, if something works locally and not on the build server pipeline; this usually points to a discrepancy between both machines, and potentially their versions of given libraries.
If you run the pipeline off of a local machine as well, maybe confirm that all libraries installed on that machine match your local ones (XCode, android-sdk, etc.)
If you run the pipeline off of a hosted machine, it maybe that the hosted images needs to be updated to a newer one to keep up with the project.
I was in the middle of working on some minor code changes when all of a sudden I started getting the following error on startup:
A host error has occurred during startup operation '78d5d8fd-e81c-4707-87ca-6b801430fef1'.
[2021-01-08T13:02:40.279Z] System.IO.FileSystem: Could not find a part of the path 'C:\Users\schiefaw\AppData\Local\AzureFunctionsTools\Releases\3.17.0\workers'.
I looked at the path and found everything exists until I get to "workers".
I, of course, assumed it was something I did, so I backed out all changes to no effect. Then I uninstalled visual studio and all Azure products I could find and reinstalled to no effect. I created a new user (since the file it is looking for is in my user folder) to no effect.
I then created an entirely new instance of a windows virtual machine and installed the development environment to no effect (same error).
I am completely stuck on this. Does anyone have any ideas on what I can try next?
Thanks!
I think this is a bug from that 3.17 release. But here is a work-around: you can add the "workers" folder (empty folder) and it should work. Another way if you have a copy of the previous version (such as 3.16.x), you can copy the content to the 3.17.0 one.
You can read more here: https://developercommunity.visualstudio.com/content/problem/1304718/azure-functions-local-debugging-broke-with-3170-up.html
I really don't know how to better explain this situation I'm running into but I'll try my best.
This is what I'm trying to do...
I currently have a batch file that does some set of actions such as downloading files from FTP, Folder creation, modifying some text files etc. This was taking us 45 minutes to do manually and with the batch script automation it's easier.
The next step I want to do is, launch our .net Windows application, login to it and do some actions in it and then log out of it. This is actually a regression test case which I've automated using VS Coded UI on another machine. The problem I'm running into is, there is a separate support team who will need to do that 45mins of job which I've already automated followed by some actions after logging into the application. That support team's machines will not have VS or Coded UI installed in it.
So, how do I go about it? Any idea, please?
You can execute the CodedUI tests you've written without Visual Studio/CodedUI being installed on the machines. Remember that you can run tests through controllers and agents in TFS or Microsoft Test Manager. You can take those principles to run them manually, even if it's a strange corner case. This takes two steps, if I recall correctly:
Design your CodedUI tests to reference the CodedUI .dlls as part of the solution, rather than the GAC. By this I mean copy and paste the required .dlls into a solution folder and replace the existing references with ones that point to the .dlls in the folder. When you distribute your tests, be sure to include this soln folder of course. (UPDATE: After some more experience wit this, I've found it much easier to use NuGet Packages instead. Project level references are an absolute NIGHTMARE)
Install the "Test Agent" software that Microsoft provides for free on the tester's machine. This will install the other testing .dlls your tester will probably need in their GAC. You could do step 1 with these as well but to be honest I think this is less trouble. In addition, it installs the necessary mstest executables.
Your testers will then have to use mstest.exe (UPDATE: Once you've installed agents, you can/should use vstest.console.exe as an alternative) in the console to run your CodedUI tests. Alternatively you canprobably use powershell or your batch files to execute your tests and your other tests in one neat package.
Please let me know if this gave you a potential solution for your problem.
I am publishing my node js site to azure using this tutorial - http://blogs.technet.com/b/sams_blog/archive/2014/11/14/azure-websites-deploy-node-js-website-using-visual-studio.aspx
I get the following error, as mentioned in one of the comments on the blog, any idea what this error is about and how do I fix this ? I am able to run my app locally no issues with that.
Error: InvalidParameter
Parameter name: index
P.s : the site is like a very basic "Hello world" kind of site, this is the first time I am using and deploying to azure too.
I created a new project as a "Blank Azure Node.js web application", and replaced the resulting package.json and .js files with what I had before, and it publishes fine now
All was working fine for and suddenly got the error! I pretty sure it something in the project as it's now happening on vs2013 and vs2015 on different computers.
Its something to do with Templates after a lot of searching. For me Azure TFS CI got things working again if possible for you?
I had this issue with some projects but not with others, all created in a similar way. So I went thought every change and every setting I could until eventually i worked it out. I didn't want to give up and just remake them.
Basically its file paths, the first thing you notice is that it errors very quickly compared to a usual publish, the first thing that is triggered is a build but unlike heavy framework languages there not really much to actually build.
Like all builds for VS it pops out a bin folder take not of where this appears. This is the key, you want this to appear in the root of your deployment usually at the same level as the publish profile.
Before I moved my projects to VS, TFS and Azure, I used to use git and used the azure push and deployment as part of git, so I instinctively structured my folders in the similar fashion with src folder and all the extra VS baggage in the a directory higher.
This is where I noticed bin folder, so re-structured my solution and made changes to .njsproj (notepad) and moved to be inline with source code and re-added it yo my solution.
Technically speaking this a bug within VS as it allows to create the project and specify different locations which is all fine unless you want to build and publish locally.
Once you get your head around what is going on you should be able to solve this problem easily and not make the same mistake in the future. If anyone is still confused comment and ill grab some screen shots.
I'm finding the BB/Eclipse environment incredibly unstable and wanted to know if I'm doing something fundamentally wrong here?
I build my project and it produces about 40 or so COD files... usually. Sometimes if I clean and run some COD files are missing and it fails to run (or worse it runs the old version somehow). I kid you not, I'm spending about an hour each time I want to run/test my setup which is an order of magnitude slower than the other platforms I work with. It eventually works by hitting the clean/debug/clean/debug/etc... and doing nothing else except these clean/debug/repeat steps.
If I make incremental changes to my src it's fairly reliable at picking them up but when I add a new resource via windows explorer and say 'refresh' on that directory in eclipse it's when all the problems start.
Any pointers from experienced Eclipse/BB users would be much appreciated (especially how to narrow down why sometimes it works and sometimes it doesn't).
Thanks,
Stuart
I believe I've narrowed down the issues. Firstly I use DropBox on the src but this has the inadvertent feature of backing up build files and can't find a way of disabling this.
If the files are locked by Dropbox it unsurprisingly fails, the catch is it doesn't say 'couldn't write to file as it's locked' or anything helpful like that... just fails. Obviously when I go to inspect it Dropbox has done it's stuff so the perfect crime!
My learnings:
disable Dropbox on COD producing builds.
When changing SDK version I found I have to
change the SDK via the build config settings,
clean,
exit eclipse,
delete the build directory with windows explorer,
Restart eclipse and hit refresh/clean.
That seems to build fairly reliably now. Without restarting Eclipse I get all sorts of wierd errors of files going to wrong locations and dirty data being picked up. The main one is any //#ifdef's are not picked up by the preprocessor correctly so get 1001 errors.