'TeleportClassicalMessage' does not exist in the current context - visual-studio

I am trying to run the Q# Teleportation sample. I cloned from the official Microsoft GitHub Repository, restored all dependencies, I have the Q# Development SDK installed also. The problem is when i run it the first time it worked now i tried running it again and i get this error.
TeleportClassicalMessage' does not exist in the current context. I run it for the last time and it worked even with the Error. I have by the way set up TeleportationSampleas my startup project.Is there any reason for this behaviour?. I am new to Q#
Even with the red Squiggly the Application run after another try.

I solved this by deleted the bin and obj directories then run again.
my experience: Quantum Program The name 'BellTest' does not exist in the current context

From my experience (playing with slightly modified sample BellTest code), Q#-generated classes are properly referenced in C# only after you rebuild project (meaning dotnet build). So if you make some changes in names that are visible on the C# side, try building it and reference issues should go away.
This was tested using VSCode on Windows 10 x64, .NET Core v 2.1.103

Related

The "References" parameter is not supported by the "XamlGTask" task

Trying to lean Xamarin in vs2017
Doing the Quickstart
https://learn.microsoft.com/en-us/xamarin/xamarin-forms/xaml/xaml-basics/get-started-with-xaml?tabs=windows
After the project is created, you have to update the nugget packages, to fix the errors on "System"
This left me in a non compiling state. So I manually uninstalled and reinstalled the Xamarin.Forms and NetStandard Nuget package via the command line tool.
It then compiled and failed to deploy complaining about .netstandard. So I manually installed the .NetStandardLibrary nutget package.
It then compiled and deployed exactly once.
Now I'm getting a
Severity Code Description Project File Line Suppression State
Error MSB4064 The "References" parameter is not supported by the "XamlGTask" task. Verify the parameter exists on the task, and it is a settable public instance property. XQuickStart C:\Users\Brown.ericw.nuget\packages\xamarin.forms\3.6.0.264807\build\Xamarin.Forms.targets 90
Error.
How do I fix this?
Is Xamarin always this flakey? I mean this is a Hello world quick start, it shouldn't' be rocket science to get it working.
Seems you did a lot of things that might have corrupted your project.
Try to clean solution & delete Obj and Bin folder & restart visual studio.
If you still have the prob, you should check if you don't have a reference in your Standard Class Library that has nothing to do here (like a ref to your droid project or whatever).
VS somtimes have this kind of flakey issue. When you Make sure the code is ok, but VS is still promote some errors. You could refer to the following ways.
Clean your project, then re-build your project.
If you still get this error, close your VS, then open the project, delete all bin and obj folders in this project, Note:If you write a forms project, you should delete three times (drod,ios, PCL), open the prject, re-build your project in the end.
If above steps.it is not work, please delete the bin and obj folder in this project firstly, copy this project to another PC that installed VS, run this code.

UWP Apps and the start menu

I've googled pretty much but i can't seem to find any information on this..
I've cloned a project from github, it opens and builds no problem. it's also added to my start menu.
I can run the program from my start menu as if it was a "normal" program.
Now I have made some changes to the sources and built it, and the changes seem to be present in the installed version (which I start from start menu) just by themselves.
my question is: is that really the case? do UWP apps get installed and updated automatically? is there a way to NOT update my installed version with my release-build every time? it seems wrong, did I miss something? (did I maybe "install" the changes somewhere along the way without noticing/by double-clicking the executable etc.) and: can I replace the executable that is started in the start menu? I tried to find where it is stored/linked, but I couldn't find anything, as there is zero information in the start menu.
Or can I rely on the start menu version always being my latest release build?
I'm confused, if someone has any information on this, I'd be really happy. :)
You are correct whenever you build and run the app on the local machine using Visual Studio it gets deployed to the system apps from where you can run it. So each time you build and run with any changes they will be updated in the system installed app as well(Basically they are same)
If you want that these changes do not get reflected in the system's app then I think you can use Device emulators available in the Visual Studio.

All project references have yellow triangles every time solution is loaded

All my project (from the same solution) references are marked with a yellow triangle. The projects are all set to the same .NET version (4.5.1). The error log says:
The project 'CommonLibrary' cannot be referenced.
A way to temporarily fix the issue is to either:
Remove and re-add the references
Right click and choose Add Service Reference and immediatelly cancel.
However, the triangles come back every time I start the solution.
The solution is build successfully regardless or the issue. The real issue is that Resharper acts like the references don't exist.
Another thing that might be relevant is that I have 2 projects that are supposed to be unloaded but they become active every time I load the solution.
Any idea what to do with the issue?
I had similar issues and it usually comes down to the Target Framework (Project>Properties>Application). I was working on a solution using .NET 4.6 and for some reason the default framework for new projects have a different target (in my case it was 4.5.2). So make sure you check all your project at the very least have the same target framework.
Do the following:
In vs choose: tools->options->resharper->options-> general-> click the clear caches button.
then close all your opened tabs and shut down vs2013.
finally, start vs2013 again.
Let me know if that worked for you.
Try switching to managed compatibility mode in VS2013
you can do that by going to tools->options..->General tab and check the Use managed compatibility mode
I had the same thing happen but didn't suspect the 24 warnings I was getting was related to this error: Error 1 Unable to locate the .Net framework aspnet_merge.exe tool on path '~\Photo Archive\Main\etc\tools'. You need to set the msbuild property 'AspnetMergeToolPath' to the folder containing this tool. ODOT.PhotoArchive.Web
Trying to set the MS build property led to a lot of research just to find out WHICH property to set. So, Agent Ransack to the rescue -- searched my drive for the most recent version of the tool and copied it to the directory Visual Studio was complaining about.
Rebuilt the project with the idea of clearing the error but then the 24 warnings also disappeared.
FYI -- this is an MVC project which will replace a classic asp project. This might be peculiar to MVC projects.
At any rate, there was a lot of chasing snipes before this was finally tried. So, where this is happening, try handling any errors no matter how remote the possibility is they're related to the issue.
I had the same problem as you can see in this picture.
Its reason was the hidden folder. I had hidden the folder containing the project files. I got rid of this problem by unchecking the hidden attribute of the root folder containing the project files and restarting the visual studio.
Check it once, you might have checked the folder to be hidden.

General failure building bootstrapper

while doing the build of my dontnet 4.0 project setup i'm getting following errors
An error occurred generating a bootstrapper: Unable to finish updating resource for E:\project\Setup\Debug\setup.exe with error 8007006E E:project\Setup\Setup.vdproj Setup
General failure building bootstrapper E:\project\Setup\Setup.vdproj Setup
Unrecoverable build error E:\project\\Setup\Setup.vdproj Setup
I am using dotnet framework 4 and MSVS 2010.
This happens because The .NET framework version required by the setup project is different than the .NET framework version targeted by the application.
To change verify this:
In Solution Explorer, click the Setup project.
On the View menu, point to Editor, and then click Launch Conditions.
Click .NET Framework.
In the Properties window, change the Version property to the version of the .NET Framework that you want the Setup project to check for and install.
And also you need to Make sure that the Setup.exe program also checks for and installs the correct version of the .NET Framework.
Right click on the setup project -> Properties -> Prerequisites -> Select the correct ones.
When I turn McAfee real-time scan off, it works. I spent 2 hours on figuring this out :(
I googled a lot on this issue after trying all i just disabled my antivirus(NPAV) and this issue was solved.
turning off mcafee real time scanning worked for me as well on Windows 8.1
Here is yet another solution, this one is unlike the rest...
We recently added NTFS replication to our build tree root to provide some additional data redundancy and to begin to sync our old build machine with the new server. The NTFS replication caused some projects to fail with the exact same three error reported, and yet other projects work just fine. Set the replication on only run at night and the problem stopped occurring...
K
I got the same error when I changed targeted framework to 4.0 but neglected to change prerequisits for click once from 3.5 to 4.0 as well.
Fixing prerequisits resolved the problem.
Instead of disabling the Anti-Virus, I would suggest to just create an exclusion for your Solution Folder. See documentation if you are using Windows Defender. Microsoft Support
I've just had this same error and then realised Dropbox was running. I closed Dropbox and then the build completed successfully.
Thank you qwerty13579! How stupid of me, the solution is obvious. I have tried all sorts of things suggested over the internet, and even with the most recent version of VS Community 2017 (15.9.9), the bootstrapper failure pops up erratically, but with increasing frequency, to the point of frustration this past week. The principle: It doesn't succeed reliably, so it also doesn't FAIL reliably. The solution: Click the Publish Now button and watch the output panel. When it's that clear that it's failing, click the Publish Now button again immediately. Keep at it until it succeeds! Each round only takes a couple of seconds, much less time that it takes to re-build, take down anti-virus, and all that fancy stuff.
In my case, I traced the problem to an incorrectly dated setup.exe file in the bin\Release\app.publish folder of my application. When it fails, Publish Now creates an setup.exe that's two years earlier than the current day. When it succeeds, the setup.exe file is correctly dated.
Got the same problem. I disabled Windows Defender real-time protection and it worked. I also added the folder where the solution is saved in exclusions for Defender, and that allowed me to publish as well.

Unable to copy file to server on build. Access to path is denied

I have a solution in Visual Studio that is comprised of 5 projects. The projects build to assemblies (.dll). I have the output path of each project set to \my-web-server\wwwroot\bin, which works fine on one project. In the properties for all of my projects, I have the output path set to the same directory, but when I try building all but one of the projects, I get the error:
Unable to copy file "obj\Release\Index.dll" to "\my-web-server\wwwroot\bin\Index.dll". Access to the path '\my-web-server\wwwroot\bin\Index.dll' is denied.
I assume it could be an issue with permissions, because my organization keeps things locked down, but I have no control over granting permissions. Any help in the right direction is much appreciated.
It must've been something silly. I deleted the .dll manually, then rebuilt. Looks like everything's working normally. Thanks.
The solution for me was to delete everything in bin and obj folders in every project. Just ran this powershell script as described here.
I had the same issue. A copy of Visual Studio (devenv.exe) was still running invisible in the background keeping the particular dll locked.
Delete all DLLs from the bin folder and build the solution.
just had the same issue, built a new project/solution, got it all working and then added to TFS.
Unfortunately I did not clean the build before adding and this meant some files that should not have been under source control were and were then read only(not checked out).
Manually deleting the files before rebuilding fixed the issue.
Most likely a program is running using that library.
This happens to me when running something to debug, and I forget to close it (not attached to IDE debugger).
And since this looks like a website, it is potentially due to the website being hosted from the development build folder, and someone is accessing it.
Similar to what Aequitarum said, it's mostly likely a locked file because it's in use. Since you have multiple projects, you mostly likely have references between them. And since you have all the projects outputting to the same folder any of the referenced projects will most likely get copied more than once if you have those files set to be deployed in the child project. (In a C# web application, you can view the properties of the reference and look at the "Copy Local" property.) And if you have the MsBuild project set to use multiple processors for the build, two child projects are both trying to copy the file at approximately the same time and one is erring out.
It's a very unique situation, but it is possible.
Working solution
Just go to Task Manager and search Detail (if its Win10) and search with your application name (for easy search just look at your windows user id wise)
And right click shows properties. just give the permission like Administrator access.
That's all its working fine for me. ( I was struggling for 1 week and its killed more my time)
It looks like WSearch Service locks up the files and does not release them. I disabled the service on WINDOWS 10 and was able to rebuild the solution.

Resources