Visual studio Project creation issue - vb.net

Ok bear with me because i am frustrated beyond belief right now.
go back about 30 minutes ago, i create a VB windows forms application. cool, nothing out of the ordinary only i make a big mistake and decide to start again. so i close the solution, delete the project folder and go to start again, only now i'm presented with
"requested operation cant be performed on file with user-mapped section open"
ok i think, there's obviously something still reading it or whatever, so i close VS completely and restart.. no avail. log off and try again. nothing. restart the computer. still nothing. what is causing this issue? i can create a C# Windows Forms Application without a frigging problem. everything BUT a VB WFA. what do i do? i'm in no real position to re-install VS right now or i'd have started 20 minutes ago. i really need a helping hand here please

Related

Scaling issue while running program (visual studio 2017)

Its probably best to mention first this issue is on a school system.
The issues is that when i start my program, the first form is fine but the second form scales very strangely so everything is small and blurry.
When I open my project I get a message saying my main display is set to 200% so I click the link to restart with 100% but the problem persists,
this issue suddenly appeared without me changing anything which leads me to believe it's an issue with the school system but I'm unsure and would be welcome to any suggestions.

Slow XAMLX Designer - Visual Studio 2013 -Workflow Foundation

The VS2013 XAMLX designer is very slow with medium sized xaml workflows.
About 10 to 40 seconds for each small change we make.
We don't want to disable the designer and work in xaml directly.
This is what we have done and tried so far (without success)
Disable Resharper
SSD Drive to speed up I.O.
Make sure the machine has enough memory and cpu...
Has anyone got more ideas on how to speed this up?
UPDATE (23-11)
This is a little convoluted, though it might shed some light.
I installed VS2015, which made a huge difference, though the workflows wouldnt work in IIS. The problem was due to a windows update which caused an error. Check this link https://support.microsoft.com/en-us/kb/3118750
I was getting errors like this:
FileLoadException: A procedure imported by 'Microsoft.VisualBasic.Activities.Compiler.dll' could not be loaded
So, I am guessing that validation was turned off while the compiler had issues.
It seems like VS2010 had a setting to turn off validation, though I cant find how to do that in 2013
Does this help at all, can anyone suggest a solution?

vb.net messageboxes not displaying

One of my duties at my job is to enhance and maintain a mature VB.Net windows application used internally by my company. We run 8 computers at the small company that each runs the app with no problems.
Recently we replaced one of the computers with a pretty standard notebook running Win 7 Professional with SP1 and for some reason, it won't display message boxes displayed using the normal MessageBox.Show("Message") method.
The vendor who sold us the computer says it must be the program, and I kind of sympathize with that view, but the fact is we have 8 other computers that all display their message boxes just fine.
Thought I'd post the issue here to see if anyone else has run into this and, if so, did they find a resolution?
I'm going to paint outside the lines a little bit and answer my own question with sort of a non-answer.
We battled that computer for about a week and a half and finally gave up and reinstalled the OS. Problem solved. Not really an answer because we still don't know what was going on or why reinstalling the OS fixed it.
Reinstalling was really an act of frustration/desperation as much as anything else. In the end we were just thankful the problem went away and we could move on. Figured I'd get this off of the unanswered questions list since I'm not really waiting for or expecting an answer at this point.

Why is debugging ultra slow in Visual Studio 2010 when stepping through Excel interop code?

To nip this in the bud, I have posted this question and workaround. I would like to accept an answer that actually quantitatively describes the problem.
I do some office programming using VS2010 and VB.NET. I have found that using VB.NET over VBA provides a much better user experience for office automation tasks. But, VB.NET IDE sometimes, not all the time, grinds to a halt when debugging Excel COM interop code, such as it takes 5 minutes to set a string equal to the value of cell, or just removing and adding breakpoints takes minutes apiece. This has been the bane of my existence for sometime, as I would have to restart my computer to fix it, but I have finally figured out the causal actions and a workaround. It happens when I have more than one other Excel instance open besides the COM server. I know Excel usually only opens one EXCEL.EXE, but, I have my registry settings so that every excel document opens in a new instance, so that I can look at separate docs on separate monitors. I don't believe this is uncommon. So, when I have left Excels open and my app starts an Excel COM server and breaks into the debugger, this is when the problem occurs, but also only if I click or operate in someway in one of the Excels after starting the COM server. Then it is like the COM server gets confused as a chameleon in a bag of Skittles of which it can't get out until I restart the computer. So, does anyone have enough debugging, COM, and Interop expertise to tell me what is causing this debugging hell? And possibly a way to preempt it?
To workaround this problem without restarting, I have found that I can end all instances of EXCEL.EXE, even the COM server, and close the IDE, then reopen Excel directly without a document and close it. Now, reopen the IDE, run code, start debugging, and stepping latency is non-existent or negligible.

Visual Studio 2008 designers screw up on large VB projects

We have 3 developers all using the same version (VS 2008 SP1) and we all use large VB projects (windows forms). From time to time, the IDE will have all sorts of issues such as locking up, crashing, and even not being able to drag a form object around or it will just instantly disappear.
On the largest of our projects (which is actually 5 projects in one solution file), a couple people here can only rebuild the project for testing 2 - 3 times before they have to close the studio and reopen it.
Has anyone else experienced this? Does this happen with large C# projects?
Yes, I experience this all the time! It has gotten better in 2008, if you can believe it.
I usually find that the reason has to do with an exception in my own code. The UI might bring in a custom control that does not behave well in design mode, causing the problem.
Sometimes, I will bring up a second execution of VS2008 and attach the debugger to the first execution of VS. Then, I can debug my own code as it is being run in the designer of the first instance. Often, an exception is thrown and I can fix my code to play better in the designer.
In other circumstances, I have no idea why it happens.
I have heard of people having this issue, however, I have never had an issue at all myself.
I have heard that a number of people trace the issues back to the use of ReSharper as the primary cause.
The most common problem I've had that causes the designer to crash is when I create a form where the only constructors require parameters.
To alleviate that, when I need the form only to be instantiated with parameters, I create a private parameterless constructor that the designer can use but which the form's consumers won't see.
I have personally experienced all sorts of designer wickedness with VS2008 sp1. I uninstalled the service pack to return stability to my dev environment. This is an unfortunate answer, but give it a try.
Only thing I've had close to this is the design view crashing and bringing up an error, formerly causing me to have to recreate the form and copy and paste the code across until I learnt how to fix it.
My problem was occurring because of me using ctrl+f a lot though. If you are using big files, this might be what's happening.