I found a similar question here, but of no help.
I have a solution with nearly 10 projects in it. I am able to edit the code while debugging the solution, but for 1 particular project (say "Defect.csproj"), I am not able to. I am receiving the error as
I have compared the properties of this "Defect.csproj" project ith other project properties and everything is found to be same. In Debug and Build tab in properties, Configuration is Debug. Optimize code is off. Can anyone suggest me whats the problem with my solution?
Are you using any special references on this project?
Using office references or delta lambda expressions can silently break the edit and continue functionality.
Also using some third party component winform items can really play havoc with edit and continue.
Also keep in mind that using linq breaks edit and continue fairly often and editing inside a try catch block on the active function is bad.
Related
I have done a bit of googling, and I cannot seem to find a solution.
I work on a VS 2013 project with 1 other person. Some times the developer doesn't check everything in, or has errors in the code. I do not always have the ability/authority to make the other developer to correct the errors.
How do I continue being able to compile the parts of the project I am working on, with out having to ask the other developer to check in or solve the errors.
Just to clarify, we are working on two separate forms/files that do not interact with each other. Is there a way to compile the current form I am working on, and run from the last successful build on the forms that have errors?
As the Title says,I am using TFS, and maybe that can be part of the solution?
Is what I am asking for possible?
You should implement a gated check-in build in order to prevent developers to check-in code that doesn't compile.
If they really want to put the code that is not complete in Source Control they should use the shelvesets.
I was wondering if it was possible to intercept or disable different Visual Studio commands or features from an extension?
For instance, could you stop a user from accessing the File -> Open command? I'm trying to work on an extension that will help enforce some coding standards and as part of that I'd like to disable or intercept a few different things when users try to do them. For instance, maybe disabling the ability to edit project properties or something similar to stop users from checking in their local changes and breaking the build or messing up other team members.
Do hooks exist for this in the Extension API or are we stuck with the old Word document asking people to play nice?
You can, but I do want to echo Greg's comment before I give details: you are better off spending your time making a really awesome tool that developers can run to catch "bad problems" than playing whack-a-mole to disable commands. Disabling commands could be dangerous because there are often multiple commands that might do the same "bad" thing. Also, disabling might cause other parts of VS to destabilize. Using your example of project properties, write a tool that runs across your codebase and looks for project files that are "bad", and spits out a build warning. Have this run every time your developers hit build. That way they still get the near-real-time feedback, without having to make sure they have extensions installed. (plus, you can check that tool into your codebase to ensure everybody is synced)
That said, implementing a IVsRegisterPriorityCommandTarget might be the right option here. The performance ramifications can be significant, so you need to make sure your implementation is fast or else you'll slow down VS. If you return E_NOTSUPPORTED from the handlers, that will result in normal routing. Returning S_OK but not forwarding would block routing from happening.
I'm working on a website at the moment that has three separate "area's" to it. Firstly, there's the main website, then there is a User control panel, and finally an Admin Control Panel.
At the moment, I am working with three separate solutions which is less than ideal, as I can imagine updating this in the future will become rather messy.
What I would like to do ideally, is create a solution, and then include the three separate projects within that solution. I don't have a problem doing that, what I can't seem to figure out however is the publishing side of things.
I've searched around and been unable to find a solid answer to my question, which is:
If I am using multiple projects in one solution, can each one be published to a separate FTP Server Directory? -- I would also welcome any ideas on how this could be done better.
My apologies if this question has been asked before, but during my searching I have been unable to find anything that relates to this situation.
Thanks in advance,
Dave
This is definitely possible, since publishing occurs at a project level rather than at a solution level. What I like to do is go to Tools->Customize->Keyboard... and set a custom key binding for "Build.PublishSelection". Whichever project you have highlighted in your Solution Explorer will be published when you push the key binding. You can save multiple publish configurations in the publish dialog as well.
I have a VS solution containing several projects. While debugging a particular project all the source files are locked by VS. I would like to unlock sources that the debugee doesn't have dependency on. Is there any way to do this within one solution?
UPDATE:
I'm using Win XP SP3 32bit. Visual Studio 2010, C#. Edit and Continue is enabled. The solution contains 6 projects (number in not important actually), 5 of them depend on the data access layer project which uses Entity Framework. None of the 5 have any mutual dependencies. They are WinForms and Console applications. I would like to be able to run one of the projects and make changes to others without stopping the first. The problem is starting and stopping the project take considerable amount of time.
The Edit and Continue feature is preventing you from editing files if the debugger hasn't stopped the program. The simple workaround is Debug + Break All, you should then be able to edit the files, your changes will be immediately effective provided your changes do not violate the restrictions imposed by E+C. This is the most efficient work flow.
The heavy-handed approach is to disable Edit and Continue. Tools + Options, Debugger, Edit and Continue, uncheck the Enable check box.
I don't think that there is a way to avoid that. While debugging Visual Studio lock all files to prevent any change on them, including those on other projects.
You can try to open the project which you are interested on with another Visual Studio instance to make changes to your files or open files singularly with another editor.
This doesn't quite answer the OP's question per se, but for anyone who has stumbled upon this page in the same (very frustrated) boat as I am, this might help.
The solution: start without debugging.
It was driving me absolutely crazy that Visual Studio would not let me edit files while the app was running. My typical workflow is:
Make some changes
Run the app to see the effects of those changes
Based on the results, make more changes, etc. etc.
The problem is Visual Studio was preventing me from step 3. It demands that you STOP running the app before you can even make any changes (including to a XAML file or adding a file to the project), which also means that you can't go back to the app to double-check something while you are actually programming it at the same time (which is how I work, bro).
Thank god I finally discovered if I run without debugging it doesn't impose this ridiculous limitation. It's still a pain in the butt if you actually need to debug something you have to re-run the app in debug mode, but it sure beats having to kill the app before it will even let you edit a file.
I am using Visual Studio and a solution with 10 or so projects in (mostly VB, some C#) which have various dependencies set up. Usually when I compile the solution it works fine. Occasionally when I do it I get a build error saying that one of the projects referenced is the wrong version (I think always the same one, possibly may be two that can cause problems). In this case going to the solution explorer and right clicking on the mentioned project and saying "rebuild" followed by another full build makes it work fine.
I assume there is something set up wrong somewhere but I didn't set up the solution myself initially and a quick look through doesn't show anything immediately wrong.
It feels like there is some kind of race condition, that VS is internally setting the version number of the project it needs before that project has been rebuilt and thus gets it wrong or something like that but I'm sure VS should handle all this sort of thing properly.
Can anybody please suggest places that I could check for whether this has been correctly set up...
And I should finally note that since I don't have reliable repro of this I may not be able to respond to questions too quickly. For example the obvious one of "Could you give the exact error message" will have to wait since I didn't think to copy it this morning, it was only after I cleared it up with the above steps that I thought to post here. Similarly any solutions may take a while to confirm.
Edit to add error message:
Indirect reference is being made to assembly ODP version 1.0.3792.16586, which contains '{{CLASSNAME}}'. This Project references a prior version of ODP version 1.0.3791.18659. To use '{{CLASSNAME}}', you must replace the reference to ODP with version 1.0.3792.16586 or higher.
Edit for more apparently relevant details
Since it has been bought up I will clarify that one of the projects is a web project and that it is this one which is generating the above error message.
Further edit
Having looked further there is a copy of ODP.dll in the bin diretory of my web project. Using windows explorer and right clicking, asking for properties and looking at the version it is version 1.0.3791.18659. Having deleted this (actually moved it elsewhere) when doing a build it recreated this file still with that same version number (ie an old version number).
ODP claims to be a project reference too which still makes me think it should just work... :(
Further Further edit
I think now that the problem is that if the ODP project changes then it gets rebuilt but it doesn't necessary cause all the projets that are dependant on it to be rebuilt. So one project might still be built against the old version and one against the new version. If they are then trying to talk between each otehr with objects from ODP then it goes wrong... I need to confirm this but I'm not sure what would need to be done to fix it at the moment. :)
Is the build order correct? I can imagine if you build one project which references the other one, and that one isn't built yet you can have this kind of problem.
Link: http://msdn.microsoft.com/en-us/library/5tdasz7h%28v=VS.80%29.aspx
If you have a website project, are you sure you have set these to be 'project' references rather than 'bin' references - you could be getting some issues this way.