So I right click on the solution > add > new project > find azure function > choose template > create that
And then nothing happens. If I swap to folder view, I see a new folder made for the function, but its an empty folder.
Weirdest thing is, this was working perfectly fine and a moment later, it became how it is right now. I've not updated vs in between, I've not restarted in between. It was literally closed vs, opened again, and then vs broke.
Older solutions that has functions in them, tried creating a new one, doesn't work same story. Made new solutions and start it off with creating a function, didn't work as well. Reinstalled vs, also did not help, still the same issue. Any ideas how I broke vs?
Also, this works from powershell, I can create functions from there and then go back to vs to add an existing project. However the functions I've build using this method had runtime errors (I think) when I publish them into azure. Regardless, I really would like to be able to create functions normally in vs.
As we can see from the comment section of the question, the solution was:
Go into Tools -> Get Tools and Features
download the .Net desktop development
As Maybemonday described in his/her comment, functions can be created afterwards.
You can solve the issues by installing the right tools.
When setting up the VS 2022 -OR- by navigating to Tools -> Get Tools and Features, install the following workloads:
.Net Desktop Development
Azure development
You can also observe the icon changes from a "Project" type to "Azure Function App" type.
I'm not sure why, but once I renamed C:\Program Files (x86)\dotnet to C:\Program Files (x86)\dotnet.delete, it started working. I think the x86 dotnet binary was earlier in the path and was causing issues.
I faced the problem: whenever I open my working solution Visual Studio automatically starts build. I cannot find configurations to turn off this.
It looks like that problem is in solution, because I opened another solution and build did not start automatically.
This strange behavior is not expected one for VS2019. Please try:
1.Tools=>Import and Export Settings=>Reset all settings=>No, just reset settings to reset current VS settings to default.
2.Use vs installer to repair your VS if there's something broken with IDE.
3.Extensions=>Manage Extensions=>Installed=>Tools you can disable(don't need to uninstall) some third-party extensions and restart VS to check if this issue persists. To check if this issue is about VS itself or extensions.
4.Exit VS and delete the .vs, bin, obj folders of the projects in the solution, and then clear the cache, for VS2019, the corresponding folder is 16.0 instead of 14.0. After that, restart VS.
For me, this was a Resharper setting. When I turned this off it stopped happening. I think there is also a setting for Visual Studio to do this as well, but it is off by default.
I have some vb code that is structured like this:
./AssemblyInfo.vb
./WindowsApplication1/AppUtils.vb
./WindowsApplication1/Form1.vb
./WindowsApplication1.Form1.resx
./WindowsApplication1.My/MyApplication.vb
./WindowsApplication1.My/MyComputer.vb
./WindowsApplication1.My/MyProject.vb
./WindowsApplication1.My/MySettings.vb
./WindowsApplication1.My/MySettingsProperty.vb
./WindowsApplication1.My.Resources/Resources.vb
./WindowsApplication1.Resources.resx
./WindowsApplication1.vbproj
I have tried several times trying to create an empty solution and then import the .vb and the .vbproj but I can not stumble on the right combination to get it to expose the build button on the menu so we can build it.
I am not a windows person so googling is difficult because the terminology is difficult to understand: Example: I use the New Project button to create a solution; that is confusing.
In short, I am hoping to get instructions that will cover:
A) Creating a new solution,
B) Importing the code listed above into the solution, and
C) Compiling the code into an .exe.
BTW: I am using Visual Studio 2008.
If you give me you best guess I will edit your answer as I try it and figure out more precise instructions.
[EDIT] When I double click on the .vbproj file on windows explorer visual studio opens and the .vbproj file is displayed as XML. No build button is shown.
[EDIT] When I do File -> Open Project... .vbproj is not listed as a supported extension so there is no way to load the project from that menu item. That menu items does not have a *.* all source option. The .vbproj file has an icon that indicates that windows knows what it is: "Visual Basic Project file". This code is the result of a decompiling an .exe of the original project where the source was lost.
[EDIT] I just followed Joel's advice, but I used VS2005 rather than VS2008 and it was able to find the .vbproj file. Does that make sense? Is there something wrong with my VS2008 that makes it not open .vbproj files or is that to be expected?
[EDIT] The version of VS that CANNOT see the .vbproj is VS2008 9.0.30729.4462. The version of VS that CAN see the .vbproj is VS2005 8.0.50727.762. By "see" I mean when I follow Joel's instructions of using File->Open Project VS will recognize the .vbproj file as something it can open.
When I double click on the .vbproj file on windows explorer visual studio opens and the .vbproj file is displayed as XML
Something is broken with file associations on your Windows system.
You can open Visual Studio first and choose "Open Project/Solution" inside Visual Studio. Doing this will makes sure Visual Studio treats it as a project file, rather than just an XML file, and will allow you to attempt to build the project.
BTW, recent versions of Visual Studio are free. You might be able to fix this by updating to a more recent version.
I installed recently the Xamarin platform and i created a default Xamarin.Forms Shared project using VS2015 and under the Droid project References i get a yellowish icon on System.ObjectModel library as you can see...
The weird thing is that in the beginning everything compiles but when i add a Cross-Platform -> Forms Xaml Page the compiler throws error on the InitializeComponent() method call.
I tried to manually reference System.ObjectModel.dll from the path C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\MonoAndroid\v1.0\Facades without any luck. When i right-click on the properties i get this
but in the file system properties everything seems to be correct.
All the above are with the default options.
Does this happen to you or it's just me? (i tested it in two computers)
If you have any questions i will update the post after this message...
Welcome to Xamarin! It's like tap dancing your way through a field of land mines. But XAML is awesome. Here is what worked for me: update your nuget of xamarin forms, do clean build, see the error/warning, restart visual studio, do a clean, restart visual studio again, do a build, spin your chair around 3 times counter-clockwise, and voila, the error is gone. It's like magic! No need to manually much around with dlls, it will just work.
Try to delete the contain of bin folder in PCL project and android project. and clean the solution try it again.
reference: http://xamarin103.rssing.com/browser.php?indx=50717177&item=8379
user: PubuduGayan, The second option that He suggested.
I hade same problem. Adding reference from C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework.NETFramework\v4.5.2\Facades... didn't work me.
What worked for me was to change (Tools/Options/Project and Solutions->Build and Run) Verbosity from normal to minimal, even if system.objectmodel reference-warning is still there.
Maybe this will work for developers too who are facing same problem
I faced the same problem. Deleting the reference helped in resolving the warning since System.ObjectModel was not used at all.
I have a seemingly random problem where my project will run using an old version of a DLL file that no longer exists. Sometimes the real version of the DLL file will be used, other times an ancient version of the DLL file will be used. Who knows where Visual Studio is getting this DLL file from - it's months out of date!
I know that it is using the old DLL file, because when the application runs I start getting weird 'TypeLoadExceptions', complaining that methods don't exist or don't have implementations.
The following actions will sometimes help, sometimes not:
Restarting Visual Studio
Restarting the computer
Cleaning and rebuilding the solution
Deleting everything in \WINDOWS\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files
Searching for and deleting instances of the DLL file in \Documents and Settings\username\Local Settings\Temp
Sometimes I perform all of the above steps, and it still uses an old copy of the DLL file. Where is it hiding it?!
The same issue exists on our TeamCity server which is using MSBuild. When TeamCity tries to run unit tests it uses an old DLL file.
Now, I know that I can use assembly redirection in the web.config file, but the version number of the DLL file hasn't changed (I don't bother to update it, so it just stays at version 1). I don't want to have to start versioning the DLL files just to solve this problem. I would just like to know which particular caches I need to clear so that I can get on with developing.
It hides it in the GAC. There it may reside indefinitely. Using a more recent version may indeed solve the problem, but there is an outstanding bug in Visual Studio that has to do with choosing the correct version of DLL files. (If DLL Hell wasn't bad enough, the Visual Studio team is making it worse!)
Finding it in the GAC is tricky, and I cannot advise you on how to do that, but once the old version is deleted from there, it will not be found again. Sometimes, even though you are pointing the compiler at a newer version (by date), it will use the older version, because it has the same version level (by version). That is its bug.
Who knows where Visual Studio is getting this dll from - it's months
out of date!
The Modules Window is your friend...
It'll tell you exactly where that file is coming from. You can even use it with arbitrary processes if you attach the debugger.
I too would guess that they're hiding in the GAC.
You can look in 'C:\Windows\assembly' to see all the dlls and unregister yours from there.
The problem may exists with the build order or your projects.
If your Test project is built before the application project, this cause the behaviour you describe. To fix this: right click on your main project in VS and select the Project Dependencies... option and check the build order. Changes to the build subsequence can be made here by correctly setting these dependencies.
I had a similiar problem (but without Visual Studio). I am loading a .NET dll using UnsafeLoadFrom.
On one computer (a terminal server) the old file still remains being used, regardless of updated version numbers, etc.
The reason is simple: As long as a program instance is running, which has already loaded the old dll, the new dll will never be used. All further UnsafeLoadFrom will become the old dll although the old version doesn't exist on the harddisk anymore, because it has already loaded some time ago.
The solution is to shut down all running instances of the application or even restart the computer. Then all new instances will get the updated dll.
In my case, this was caused switching to Release mode, which had a different configuration (that used different location of the DLL).
In my case, I use Visual Studio to Publish Website, and though I check the reference of the dll file has changed, but the published dll still is old. Finally I new a Publish Web Profile and choose the right configuration (such as Debug - x86 / Release - Any CPU), publish again then the dll is corrected.
While this question is old, maybe someone will stumble upon it again in his/her quest for finding a solution.
In my case i got a CS0433 error for an ASP.Net page. After deleting the content in the obj\ and bin\ folders of the project, it worked again. Probably has to be done with a closed Visual Studio. Maybe also clean out those folders in referenced projects in the same solution (if used in the project and not pulled via Nuget).
In my case, the old DLL was in
C:\Windows\Microsoft.NET\assembly\GAC_MSIL\MyDLL\MyDLL.dll
It DID NOT show up in c:\Windows\assembly.
I did a search of my drive for MyDLL, and it showed up as indicated above. I was debugging my test app at the time, and tried to delete the offending folder...no go...it was locked by Visual Studio. I had to stop debugging my app, close Visual Studio, and then delete the folder. Problem solved!! I don't know how my DLL got there, but it hasn't showed up there since I deleted it.
It's possible that the DLL is being referenced from another folder. It could even be on a network drive if you have one in your PATH environment variable. Here's how Windows searches for DLLs:
http://msdn.microsoft.com/en-us/library/7d83bc18%28v=vs.80%29.aspx
In My Visual Studio 2015, I ensured that the offending Visual Studio project's Reference Path Listing is empty:
If you find such problem ,delete your Reference dll and pdb extensionfile add new references and rebuild your project .This often happens due to no rebuild of project,commit and updates.
The fix for me was making sure that the virtual directory in IIS was pointing to the correct directory. I have two projects on my system, a v4 and a v5. The virtual directory on my dev system was pointing to the v4 bin directory instead of my v5 bin directory - oops!
The file that was being cached in the dll, I couldn't trace the file, so I ended up renaming the file. This might not resolve the problem mentioned here but this was the fix that worked for me related to this question.
I tried a ton of things including re-installing VS 2107.
You can see where the DLL files are being loaded from in your Output window. After going through all mine looking for project DLL, I found it.
Clearing this worked for me.
C:\Users\YourUser\AppData\Local\assembly\dl3\222Q4G1T.8AT\JBEAR7PB.E3J\8bfcf9ab\6e61cbd5_30acd401\YourDLL.dll'
I actually deleted all the files in:
C:\Users\YourUser\AppData\Local\assembly\
Holy Crow! I had an old, old suite of applications including 2 web services and a bunch of class libraries and a click once application. Well, click once stopped publishing for VS 2005 with a bunch of 'not found' errors. So, rather than hack away at my registry as suggested on this site, I figured it was time to upgrade the projects to 2017. Well, when I did this, the projects references in my web service projects got lost. Then, rather than helpfully just telling me that with errors, VS 2017 must have went to some cached file in C:\Users\XXX\AppData\Local\Temp\WebSitePublish or C:\Users\XXX\AppData\Local\Microsoft\VisualStudio\8.0\ProjectAssemblies or C:\Windows\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files\root and 'helpfully' just used those files instead! I had to do a hardcore search with a custom program to find all the files on my C:\ drive and delete them before I finally got the errors!