I am having some issues with VS 2012 code editor adding random
into my code in large amounts. And a co-worker is getting repeated text from literals, ie. Bondability would end up BondabBondabBondability for no apparent reason. He has also had starting tags affected.
These issues tend to happen when we save the documents. We are using asp.net with vb.net and running windows 7.
Any leads as to why this might be happening would be greatly appreciated as google has failed us thus far.
Edit: My Co-Worker uses Split mode heavily and that is where he is noticing his changes. The changes do not always occur in the portion of the page that he is actively changing either. I do not use split mode and only view the designer occasionally, and have noticed that the non breaking spaces show up after I have done so, but not every time.
Related
I have a really strange issue. I just moved my ColdFusion application from ColdFusion 8/IIS 6 to ColdFusion 9/IIS 7.
None of the HTML files were modified; just copied and pasted to the new server's web root. But the pages are rendering slightly differently. It's as if the CSS margin settings and padding settings for the layout are not being applied in the same way. The elements are bunching together whereas there was proper spacing before I moved the application over.
I thought ColdFusion server wouldn't interfere with any formatting of HTML pages as it just handles back-end requests, but these pages clearly look different on the older version of ColdFusion/IIS.
Is there anything that would make this happen in ColdFusion or IIS? I'm just using CFM pages with basic CSS styling, etc. Nothing crazy.
I'll brave an answer. Here are some things to try (or at least think about):
I am assuming that there are no errors and that just the HTML is wacky (but workable).
In your CF Admin head over to 'Settings':
Look for 'Enable Whitespace Management': (which described) Reduces the file size of the pages that ColdFusion returns to the browser by removing many of the extra spaces, tabs, and carriage returns that ColdFusion might otherwise persist from the CFML source file.
See if it is checked if not check it and see if you notice any changes expected or unexpected.
And look for <cfsetting> tags with the enablecfoutputonly set to no/yes or true/false or 0/1 (or lack of the parameter)
Next is: <cfprocessingdirective>
Look for page that does this:
<cfprocessingdirective
pageEncoding = "page-encoding literal string"
suppressWhiteSpace = "yes|no">
</cfprocessingdirective
pageEncoding = "page-encoding literal string" <<< this could do some things to on a character level that you might consider.
See Adam's colorful post here for encoding details.
Provides the following information to ColdFusion about how to process the current page:
Specifies whether to remove excess whitespace character from ColdFusion generated content in the tag body.
Identifies the character encoding (character set) of the page contents.
Also check for these <cfcontent> and <cfsilent>
Maybe that will unravel some mysteries for you (Or make more depending what you find when you run some searches through your code)...
On a last note. I am not sure what your code base contains, but if you run into some things you can consolidate consider using the Application.cfc then move all these white space encoding things here. Somethings do similar things to others so you might want to clip the redundancy to a single point of failure that way you don't have individual pages replicating actions when they don't need to.
Oh, one last thing, make sure you turn your caching off because some of this sounds like someone trying to beat overhead on pages. If you have caching on and render pages while you are making changes you may not see your fixes and then you will pull your hair out. We don't want that.
:)
Good luck.
we are in process of switching our ASP.Net development from Visual Studio 2003 and .Net 1.1 to Visual Studio 2010 and .Net 3.5. So far, we successfully migrated our back end code and after some fight the ASP.Net front end code too. While the work on the back end code resumed with usual productivity, working on the ASP.Net front end code is massively hampered because of following issues:
The Visual Studio 2010 Web Designer crashes frequently (e. g. after using the "Undo" function) - we are used to the stability problems of Visual Studio 2003 Web Designer when working with large web forms, but the new Web Designer crashes frequently even with trivial web forms. Is there anything to make the thing stable? ServicePack 1 brought no help.
When adding new controls to a webform in the web designer, the declaration of the new control will never automatically propagate to the code behind page in the migrated web form. New web forms created from scratch seem to work ok. The migrated web forms maintain the old file structure (aspx, aspx.cs and aspx.resx), while the new web forms get a new file structure (aspx, aspx.cs and aspx.designer.cs. Recreating all the existing web forms manually to get the new file structure would be a very painful operation. Is there a way to make the old decent working propagation of controls' declaration to code behind file work in Visual Studio 2010 too?
(Currently our biggest problem): when designing a web form, we basically put the textboxes, labels, buttons etc. in a div with ms_positioning="GridLayout". We define absolute coordinates for every control in the div. This doesnot seem to work properly in Visual Studio 2010. With a lot of effort we can somehow continue using this approach, but adding a new button or textbox to a web form means massive effort now. Without paying really much attention it can even result in overwritig of the css-classes-file (the Web Designer sometimes decides to write the coordinates not in the aspx file but in the css file). I read recently that using absolute coordinates to position stuff on a web page is a very bad and deprecated approach. I tend to believe it seeing how gruesome it has to be done in the new Visual Studio. But what is the correct way to create winforms-like web forms rapidly? (With rapidly I mean simple drag-drop-point-click way of designing stuff).
Thanks in advance for any help.
Best Regards
Erich Horak
I'll try to tackle this issue by issue:
Designer
Unfortunately, the new designer in Visual Studio 2010 has been plagued with issues. With 2010, the editor was completely revamped with WPF, which was supposed to make it faster, but thus far has seemed inferior to the previous editors. There are some improvements, but if I had an option to choose I would stick with the old editor, at least until the issues are worked out with the new one. It may not be any consolation, but you are not the only one feeling that pain.
Adding controls/new page file structure
Again, this is another situation where migration will prove painful. If I were to suggest an approach, I would copy paste the markup into newly created forms (created w/ VS 2010). The designer.cs file should register the controls. You might run into issues with event handler mappings, but hopefully it won't get in the way of the designer.cs file registering the controls. I know this is a painful prospect, but you have to keep in mind that you're moving up several versions.
Designer view & absolute positioning
While you're migrating the system, you might want to set the default view to source-view, so you can paste the HTML onto the page. You can do this by going to Tools > Options > HTML Designer > General. Honestly, in my opinion, the designer is really flaky and should be avoided. The HTML it produces really is horrible.
Using absolute coordinates to position elements on a page is a deprecated approach for sure, but if your goal at this point is to get your migration working, then don't worry about it for now. Eventually, it would be a good idea to refactor your HTML and CSS to use more modern techniques, but if the current code-base is browser-compatible, then leave it for now.
It may not seem like it at first, but if you can move away from the designer and use the source view, you won't regret it. It does take a little more time at first, but having control over the markup will end up saving you a lot of time in the long run. If the designer is allowed to run rampant throughout the system, it will screw things up. By using the source view, you have full control over everything that's happening, which will become a huge advantage. By leveraging new features like master pages, you can move just as quickly in the source-code view as in the designer view of 1.1. I started out with the designer-view myself in 1.1, but after switching to the source-view, I never looked back again. You really do make up the productivity in other ways.
I wish I could give you a "do this and everything will snap into place" kind of answer, but I think you're in for a painful conversion process. The good news is, once it's done you can start utilizing all of the new features that have come around in the past 8 years. ;)
I see no quick, drag & drop way of doing this. Things like GridLayout are deprecated; much easier in the long run to port the forms manually, cleaning up the markup as you go and using the code view of the forms instead of the design view. Also an opportunity to write clean, separate CSS rather than inline styles.
Post 1.1, you do not need to declare the form elements in the code-behind - the new partial classes obviate the need for that. So this is just one more thing that is different. I am actually working on a similar project right now; I availed of the new master classes which meant changing quite a bit anyway.
My honest advice is to suck it up and move on :)
I asked a similar question here:
Visual Studio Multi-Project Solution Options
We have an ASP.Net menu that works fine for everyone except for one developer.
We verified that the source code on his machine is identical to everyone else's. We checked the generated HTML and verified that it is not a display problem. We stepped through the code and made sure that the menu control was set to visible in PreRender.
The really strange thing is that this problem has only been occurring for him in three separate branches. Yet this problem has never been reported in QA or production. We also checked/verified that this problem occurs across all three major browsers.
We cannot show you our code due to the nature of this application. If anyone has ever experienced a similar problem or knows a resolution we appreciate your help.
It sounds like the dev workstation is polluted in some way. Either there's something cached or a system setting somewhere preventing this.
I'd say that if this problem can't be reproduced on any other machine/VM/customer, then don't worry about it.
Have you distilled the problem with a sample app/menu, or is it just in that one particular application?
I've got this very odd bug that appears to be a quirk in Visual Studio 2010: Sometimes, when moving the cursor into double quotes of a CSS style="" attribute the cursor refuses to move. I can't type anything, and the keys that respond are the UP/DOWN cursor keys and the DEL key (but not BACKSPACE).
Typing does nothing, but pushing LEFT/RIGHT on the cursor keys produces the following error:
The operation could not be completed
I've got no idea what's causing this, but I would hazard a guess that Intellisense is getting very confused and bugging out.
At the moment, whenever this happens, I have to write any CSS outsite of the double quotes of the style attribute and then place the cursor where I want the CSS to appear (using the mouse) and press CTRL-V to paste it in. Very annoying :(
There must be a way of fixing this problem...?
Hopefully someone has an answer!
Just encountered the issue in VS 2012, in editing C#.
I noticed that the problem had occurred soon after the trial period of Resharper has ended and i inserted a valid license number. It also happened in only some of the source files.
The solution: Tools->Options->Resharper: Suspend.
Try typing - should work now.
Then: Tools->Options->Resharper: Resume.
Problem gone.
I have encountered this using Visual Studio 2013 and Resharper 8.2.1. None of the solutions provided in this thread worked (even suspending and resuming Resharper)
After contacting JetBrains support, it turned out to be a caching issue.
Deleting all the files from the following directory solved the issue, as Resharper re-creates new caches:
C:\Users\[Username]\AppData\Local\JetBrains\ReSharper\v8.2\SolutionCaches\[Project_reference]
I have some odd issues with the editor occasionally, a workaround for me is:
Ctrl-Tab (x2) to another code file and back to the same code (or alt tab to another app and back, one of these two... can't replicate issue to be sure)
An ultimate solution might be a re-install.
Microsoft have had variations on this problem reported quite a few times via their support portal. Here is one post and if you scroll down you will see a comment with a bunch of other reports all detailing similar(ish) problems.
Microsoft doesn't seem to be able to reproduce the problem but are "duping all the similar keyboard locking problems to a central bug, so that we can think a way to log the events if necessary". Which seems to be a generic response to a lot of these posts. Some people reported that it was simply becuase another window/pane/tab was in focus but I can see the OP obviously did not have this specific problem. Looks to me like one of those random unresolvable bugs. Hope I never get it! There's also numerous forum posts around the Internet, where users stated that removing certain 3rd party plugins has solved this issue.
I just spotted this particular post which has a possibly useful comment on it for you (which also link to this SO post. As I do not have the bug I cannot test its validity for you. The main point of it seems to be something about the keyboard layout switching.
I'm sorry for putting all this into an answer when technically it is not an answer and just a mass of research, but there was no way this was gonna fit into a comment. And also sorry for pretty much link spamming, but again there was no way I could extract everything that they said into this post. I hope there is something useful in there for you :)
EDIT: You should probably check the top rated answer below as this seems to solve a number of peoples issues, although I never had the Resharper plugin and still occasionally experienced this, but now I'm on VS2013 and have not had this problem re-occur, so maybe they fixed it...
Empty the solution cache folder
C:\Users\{UserName}\AppData\Local\JetBrains\ReSharper\v8.2\SolutionCaches\
This was suggested by JetBrains support when I contacted them.
Permanently fixing... Not too sure however I found that pressing pressing Ctrl+Shift+Caps Lock+Tab all at once seems to get rid of this and enables the mouse and keyboard again. I know this isn't the best of solutions but it works.
I have the same problem several times a day. I didn't notice it until I installed the web essentials extension. I just uninstalled it and will see what happens. I have tried reinstalling visual studio with no joy (but again, I didn't notice the problem until after I had already installed the various extensions).
Sometimes, closing and re-opening the specific code window I'm working in fixes it. If that fails, sometimes I close all windows and reopen just the one I was actively editing. If all of that fails it usually requires a complete restart of visual studio.
I find it funny that MSFT says that they can't duplicate the problem. Scott Guthrie experienced it first hand during his MVC4 beta demo here at about 28 minutes in.
UPDATE: So far, as of 4-5-2012 9:33am Central Time, the problem hasn't recurred since uninstalling Web Essentials. This is the longest I've gone without this bug occurring. If I make it through the next 24 hours, I'll be confident in blaming Web Essentials.
UPDATE: 4-6-2012 10:05am Central Time: Well, apparently it wasn't Web Essentials. It happened to me again this morning editing the contents of a block in my _Layout.vbhtml file. Closing the tab and reopening it fixed it.
I frequently encounter this editor freeze, not just on CSS quotes but any file arbitrarily. I have a dual monitor setp and I have the doucment windows one one monitor and all tool windows on the next one. Sometimes, certain tool windows would freeze too (i.e. not respond to click).
Previously, I used to shutdown/restart IDE; but serendipitously, I discovered that switching to/from Full Screen mode, restores sanity. So now everytme I see a freeze, mode switching comes to rescue.
Not sure if this will solve your issue, but worth a shot.
Rant: In general, I find this new WPF based product very falky and unstable than its predeccessors.
I have the same problem on IDE, some times the Return key is not working at all...
My solution is: CLEAN the project/solution.
BTW: CLEANing resolve also other unexpected behaviours after amendements on CSS or HTML.
I tried every other workaround here but nothing seemed to work, and the issue was only present in one solution but not another.
Disabling Resharper fixed it temporarily but it came back after re-enabling it which wasn't a viable long-term solution.
What worked for me was disabling all Resharper Extensions (Under Resharper -> Extension Manager). I was able to type again even after re-enabling all of them, so I'm unsure which extension specifically caused the issue, but that's another route to try for people who still have this issue.
I never had the problem until I installed plugins/extensions. Curious to know if anyone has had this problem without having any plugins/extensions installed. I don't know if they are the actual cause but since benefits of the plugins outweigh the occasional lockup, I have left them installed. BTW, I use the "closing/reopening of the window with the lockup" technique.
Using a source control (GIT, AKSVN)? If so, disable it, restart VS then enable it and open the solution again.
I've taken over support of a legacy web app written predominantly in classic ASP. One page has a form for doing a job estimate, and consists of about 2500 lines of javascript and ASP code to achieve a "transparent edit" - i.e., the form is always in edit mode, and changes are instantly updated into the DOM.
There is also a "Print To Word Doc" button that, when clicked, goes to an entirely separate ASP file that produces (supposedly) the same view in HTML sent downloaded to a Word document.
The problem is that we have discovered inconsistencies and bugs in the two versions that are produced. My first response, applying the DRY principle, was This needs to be re-written in ASP.NET with a single code-behind file outputting the view for both the web page and the word document, so that we have one place to maintain the source.
However, upon getting into it, I'm questioning the wisdom of that approach, and I'm soliciting advice.
The problem is that, because of the integration of the view with the editing on the web page, as opposed to simply presentation on the work document, the two functions really do have two different purposes. Also, the ASP code, while ugly and hard to maintain, produces a reasonably nice-looking document. Doing the same thing in ASP.NET, at least using ASP.NET controls like FormView, is proving challenging. (One of the rewrite requirements is that the new page must function like the old page, minus bugs, of course.) The integration of the javascript to accomplish the editing functions on the client side makes for a good UX (assuming they work correctly). I can probably accomplish that same thing with AJAX and/or jQuery, but I'm wondering if I'm really gaining anything here.
How would you handle this?
You also have to take into consideration a couple of other issues:
How critical are the defects?
How
much time to do you have to get this
thing fixed?
How long will it take
you to correct the defects in classic
ASP?
How long will it take you to
convert the entire thing to ASP.NET?
At the end of the whole thing, will
anyone care which platform it's
implemented in? That is, will they
still be able to get their work done?
Because, at the end of the day,
that's all that really matters.
ASP.NET, while a wonderful thing, is not a silver bullet. If you're spinning your wheels, you're not being productive, and no one's getting a fixed product in a reasonable timeframe. It's like refactoring code just for the sake of refactoring it. It doesn't fix any defects, but darn does the code look pretty.
My advice to you: stick with classic ASP until you get the bugs out. THEN port it to ASP.NET. I'd much rather port a fixed product than a broken one.
That's a really complex question you're posing. The main issue is right there at the end:
I'm wondering if I'm really gaining
anything here.
Is the modification you need to make a small mod? or is it large? How much will you have to maintain this in the future?
You'll only realize dividends on your effort with future modifications. If you're never touching this system again, re-writing won't realize any benefits.
I have worked in projects in which we "converted" a classic ASP application into a .NET application. This is what we did:
Made a copy of the classic ASP files and then used the automated conversion feature from Visual Studio to convert this new copy into a .NET application.
Listed the .NET features we wanted to take advantage of in this new application and then found the correct places in the application to implement them.
Re-wrote code where needed to take full advantage of such features.
Refactored existing classic ASP code to avoid re-inventing the wheel where it was not needed.
Tested everything and then ran both applications in parallel until we felt comfortable that the new .NET application was running as expected.