our team is starting to dread updating the service references in our solution because it's a 5+ minute investment. Everything is localhost inside Visual Studio's web server.
My question is - how can I debug what this problem is? It works fine once it is over, but the long delay is crazy. If I had a clue where to look, perhaps I could resolve this.
With VS2012, I ran into the same issue: it took me almost 10 minutes just to update one service reference. I just managed to fix this by re-adding the service in the following way:
Delete the service reference.
Right-click "Service References" and select "Add Service Reference".
Click "Discover" (required in my case, might be different for others).
Select the service that you want to add under "Services".
Give the service a name (under "Namespace" at the bottom").
Press "Advanced".
Uncheck "Reuse types in referenced assemblies" and press "OK".
Press "OK" to add the Service Reference.
For me, the reusage of types was the big issue: now that this is unchecked, new updates only take a few seconds. Since I couldn't find this solution anywhere else, I thought I'd just post it here in case others run into a similar issue.
More than likely the .suo files have gotten ridiculous due to constant refreshes. You can check this by examining the source. If this is the case, you can delete the .suo and update the reference. You might want to make a backup, just in case you forgot some other user settings you have.
The other option is the WSDL for the service has just gotten too damned large and you have to bite the bullet.
If you want to reduce the impact, get the service guys to nail down the contract by using a little known secret called planning. ;-) Honestly, poor planning is often the root cause for a lot of the issues that crop up in VS.
I noticed that using svcutil instead of Add Service Reference in Visual Studio leads to shorter generation times, albeit sometimes the code generated is slightly different (more on that later).
At work we have a WCF service composed of about 100 service operations and 100 service contracts and the proxy generation in Visual Studio 2012 starting from the WSDL exposed by the service takes about 7 minutes. I then tried to use svcutil (without any option) and the generation took only about 2 minutes.
I had to add some options to match the same characteristics configured in the service reference (/enableDataBinding, /serializable, /namespace:*,myns, /syncOnly and collectionType:System.ComponentModel.BindingList'1) and with this option the generation time raised to 3 and a half minutes. Overall the proxy generation is not order of magnitude faster but at least the generation time should be cut in half.
In my experience the two generation methods have some differences that I'd like to point out:
Visual Studio generates datasource files (the one generated by Visual Studio when adding an object datasource to a Windows Forms project, see also this SO thread); svcutil has no option for generating them. It shouldn't be a major problem, since the first time you need to databind to a contract the file should be generated by Visual Studio.
As an aside, if the proxy is compiled in a separate assembly, the referring project could not reuse the generated datasource files since they are not included in the assembly and they will be regenerated anyway.
the ConfigurationName property of the Service Contracts can be different, apparently because the two generation methods consider differently the target namespace in generating the attribute value. This is a problem in our case since we do not use the generated app.config. This however can be managed easily by changing the app.config to match the new value or by (automatically) changing the ConfigurationName property in the generated proxy source.
svcutil does not decorate the ExtensionData property with the attribute Browsable(false) -- this can be a problem if (like us) you use the data contracts as source for databinding in Windows Forms, since all grids now will acquire an additional column for ExtensionData. Like the previous hiccup, this can be handled by adding the attribute using a sed-like tool (for example, I used the PowerShell snippet contained in this answer).
I faced this same problem just now, and updating my service reference was taking around 10-15 minutes sometimes it failed to update. I was frustrated and finally I deleted the reference and then added it once again. And now everything is working fine.
So, I will suggest you to delete the reference and add it again and lets see what happens
Had a slow problem updating webreferences. I was crasy about the times. More than 1 hour.
Some co-worker told to to add my workspace path to exclude from Windows Defender and it solve my problem.
Related
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.
In the last year I've worked on two relatively large .NET projects and both of them have ended up with project/code generation strangeness that I just haven't figured out how to fix..
The first project generates some bad code for forms that causes the VB.Net build to fail. I actually had to make a search/replace macro that fixes the 5 problems by adding a Global. to the beginning of a few references.
I chalked that up to a random act of unkindness against me and went on my way since the macro takes about 2 seconds to run...
So now 6 months later and new project is cranking along and I get a similar-ish problem. I have a bunch of form controls that store state in a settings file using the built in capabilities of .Net. I had about 20 controls that were configured automatically this way. Works great until today when for reasons I don't understand in the designer.vb file gets corrupted. At least one other person on the planet has had this problem here:
http://social.msdn.microsoft.com/Forums/en-US/winformsdesigner/thread/9bd20b56-7264-4a1f-a379-ad66b372ddd3
but the proposed solution didn't change the behavior.
So now I've had two projects (larger ones) that have project file issues that I can't resolve (I've had several smaller projects that are just fine).
What tools are available to fix projects, migrate projects, lint projects ... anything to recover projects to a reasonable state? Any successful recovery procedures beyond a roll-back/merge?
i had a corrupted reference issue linked to my use of mercurial and VS getting lost in file save time... if this may help...
If you open it in notepad and its corrupted - then its probably corrupted and the only way to restore it would be to go to a backup.
--> go to backup
-->click your project name
-->and then find your fire thats are corrupt
My company are working at Sharepoint site that we are developing using Visual Studio. The actual installation at the customer is performed by scripts deploying the produced wsp-files. During normal development I mostly use deployment from directly from inside Visual Studio. Unfortunately I often run into problems when trying to deploy my solutions. We are using a server-farm set up, but each developer has their own virtual server, datebase instance and so on.
We have one project file that the define the basic content-type used for different department. This content-type typically define stuff like what period that the list item cover. Each department have their own project that uses the content type combined with department specific fields to form the final list.
One of my current problems is that when I make edits to the content type and deploy it the changes does not seem to propagate. Even though I rebuild the solution and deploy both the base project and the department project with success I still see the old version of the content fields when I create a new department list. Sometimes it helps to retract the projects, but often I literally have to restart everything before it works.
My question is if this problem is caused by Visual Studio not really deploying my new defintions or if there is some architectual aspect of Sharepoint 2010 that might prevent the change to propagate. What steps can I take to lessen the likelihood of the problem occuring?
Have you tried deleting the content type with Central Administration before doing a new deployment? I've found out that Sharepoint don't update/create content types when it finds other one with the same name.
On the current project I am working on, there is, at the moment, a large churn of code, which means updating from source control can mean at times many csproj file changes. As we all know, VS2010 doesn't have a "Reload all" button, but you must reload each project and confirm each reload.
Is there a method where either the project is auto-reloaded or the IDE can detect this and ask for a solution reload?
Finally found a solution:
http://lostechies.com/jimmybogard/2011/01/27/reloading-all-projects-with-vscommands/
Quoting from the site:
Quite often I’ll find myself working
in situations where multiple projects
have changed, and Visual Studio asks
to reload them, one at a time. This
happens when I’m working a lot with
source control, and doing things like
switching branches, performing merges,
or just integrating upstream changes.
I have to click “Reload” a million
times for each project that changed on
disk, and it’s quite annoying. On top
of that, VS forgets which files I have
open, so every file that I was working
on gets closed.
I may be the last VS user to find out
about this, but a free lite version of
the VSCommands plugin is available on
the Visual Studio Gallery that does
just what I need – reload all changed
projects at once, preserving which
files I had open:
It's a pain, but the best option I've found is to Close the solution before Getting the latest source code.
If there are more than two changed projects, it is faster to manually unload&reload the entire solution than it is to Get and wait for it to unload&reload the affected projects only - reloading projects is achingly slow (even disregarding having to click the OK button for every project that changed).
(In my mind the real question is: Why does it ask that question at all??? If you Get the latest source code, there is absolutely no sane reason why you would want to only use part of it. It's like a petrol station attendant saying "You've bought some fuel. Would you like me to now actually put it in your car, or shall I just pour it out on the ground?")
Well, that doesn't work if your references paths changed in the csproj file and your using something like the sysinternals junction tool to change a symlink. E.g. tool switches D:\Projects symlink from D:\Baselines\1.0\Prjects to D:\Baselines\2.0\Projects , and because someone changed the folder structure between 1.0 and 2.0, your .csproj file suddenly points the dll path from ....\References\some.dll to ....\References\3rd-Party\some.dll . I know that is a special case, but happens (e.g. in my company).
There is an alternative solution though, one which I highly recommend as it has other benefits, too: the not-so-well-known VS 2010 Extension Solution Load Manager. It defers loading of Projects to the background, or until manually loaded, improving solution load time a lot for large solution files. It has this "reload solution" button in it's menu (unfortunatlely there seems to be no shortcut) which then reloads all solutions from scratch, skipping/backgroundloading the solutions you set. A Microsoft guy commented on his blog that they wanted to include something similar into VS 2010, but the feature didn't quite make it.
Sure, it may take longer then "just" one click and updating 100 documents, but it solved my problem of (relative) reference path changes, and gives a nice speed boost every time I open an at least medium sized solution.
Edit as of Oct 2013
VS2012 includes this functionality by default. At least the async loading stuff. The "don't load at all" functionality is unfortunately only possible by using manual "unload project" in VS2012. But as pr-project memory consumption did go down with VS2012, it's not that big of a deal anymore.
If you have checked the option "detect when file is changed outside the environment" in the "Documents" section of options, projects and files are reloaded when changed. It works for me when switching branches in git.
I have a website solution which contains a project with domain classes.
I have added a public auto property (get; set;) to one of the domain classes. A page on the website references this property - it was added to the page using IntelliSense.
The website project builds okay. But when I build the solution, I get the old 'Class does not contain a definition for Property' error. However, if I right click on the property in the aspx.cs file, it takes me right to the declaration in the domain class.
The other website project in the solution can call this property of the class without errors.
Actually using the website fails with the same exception.
Seems like Visual Studio is having some kind of weird episode here.
Any suggestions what might be going wrong?
Thanks
David
Edit: Here are some further observations in a series of steps.
Clean Solution (says 14 succeeded; there are 16 projects in the solution)
Build Solution (says 16 succeeded)
Rebuild Solution (fails as described)
Build Solution (fails as described)
At no point does the website actually work - it always gives the error.
It does appear to precompile successfully.
Edit 2:
I have removed the project reference and re-added it, but the problem remains.
Edit 3:
I have added a new webiste project to the solution and copied all the files across from the existing website to the new website. The problem exists in the new website as well as the existing one.
You might try using System.IO.FileSystemWatcher or one of the SysInternals tools to try to find out if the compiler is accessing an old, cached copy of your assembly somewhere.
Perhaps a reset of IIS or the Application Pools helps a bit?
Also, if the assembly is registered in the GAC, perhaps removing it and installing it back again might help.
Double check the Build Order and/or Dependencies on the project that is having difficulty finding the property. That project should require that the other project(s) build first.
Okay, the problem was that the class I was using (which reportedly didn't contain the particular property) is called Case. Despite C#'s supposed case sensitivity, presumably it somehow clashed with the reserved word 'case', and this caused the problem during compilation.
Fully qualifying the class name fixed the problem, but I think I might just rename the class 'ProbateCase'.
I have to say this is clearly a bug in Visual Studio's compilation process. Not only should 'Case' not equal 'case' in c#, but also the class has existed in my solution for about a year and a half and this problem has never arisen before. Other projects can freely use the class without qualifying its name.
Grumble over. Life goes on.