Occasionally, when performing certain actions in Visual Studio, things seem to go 'haywire' - Visual Studio launches many, many instances of the 'Development Server' - multiple icons appear in the notification area, multiple successive 'toast' notifications pop up etc etc.
Both of the solutions I have this problem with contain two web projects, one of which is set up to use ASP.NET forms authentication.
I am also using the Perforce source control plug-in. These solutions are under source control.
Actions that can prompt this behaviour are things like, creating a content page from a master page, clicking on the 'Configuration' icon at the top of the solution explorer. Ironically, actually running one of the projects doesn't seem to cause the same problems.
Once things have settled down, I end up with a notification area that fills half my taskbar. 'Running' the mouse along these icons then causes them to disappear, in the same way that you sometimes get with applications that have terminated unexpectedly.
This is becoming pretty frustrating as it tends to block things I actually want to do!
Grateful for any advice. Hopefully I've been sufficiently clear - it's not a straightforward issue to describe!
Thanks,
Jamie
Please check out the blog post at http://vishaljoshi.blogspot.com/2009/08/multiple-instances-of-visual-studio.html
Did you check the "Properties" page (right-click of your solution file) of your solution? You should be able to set the starting project there to "Single Startup Project".
Sounds like the Web Configuration service is failing during startup and VS is trying to restart it.
I would either stop using that tool--it always seemed overkill to me once you learn how to manipulate web.config and get your basic user/role admin CRUD pages on the site. But it may just be some bad data in your authentication database, if you're using the built-in Membership providers, etc. If it's development, try using the aspnet_sqlreg.exe (or whatever it's called) to remove and re-create the Membership, Profile, etc. database tables and stored procs.
But first, I would check the Application event logs and see if the exceptions there help you track down the issue.
Related
I have a problem with an old application in asp.net.
This application runs on a server with windows server 2012 and is used by hundreds of people at the same time (same app but which is pointed to by different domains).
The problem is this: every time I modify an .asp file, the page takes a lot of time to "recompile" the code and this causes damage to the users who use it.
This problem does not occur with the exact same application but running on another dedicated server used only by one user.
I've been researching for days, the only noteworthy thing found is that, in the server iis, if I recycle on application pool -> select the application, it has exactly the same effect.
I don't know much about windows server so I ask you for help.
Thank you!
You have two types of deployment models.
First is what we call a asp.net web site,
and then second, is what we call a asp.net web site application.
They sound the same - but they are not.
So, while most perfer using a "application"? The ONE down side is that you have to re-publish the WHOLE site if you say change some code behind. This is good, and bad. The good part is that your code is re-compiled BEFORE you publish. (and in fact, you might even want to re-name "app_code", since that does re-compile by the web site.
However, for the most part a web applcation is "harder" to make a small update, since when you publish, you have to re-publish the whole site. But, the good part is that all code tends to be compiled down to ONE .dll. In effect the the site is pre-compiled before publishing. And with a applciaton, then you can add/change and do more things. In effect, the web site "applcation" allows you to do things like create say a custom logon provider. In most cases, this means the WHOLE site is under your developer control. It also means that code behind (source code) is NOT pushed up to the site.
Then you have what is called a asp.net web site. This allows you to say modify the code (code behind) of one page and then push that one page (and code) up to the site. The web site will thus re-compile that one page. You will note the "delay" that you experiance - but it ONLY occures the first time that page is published.
So, for a "application", you will in Visual Studio open up the project (and a sln file) is used.
For a web site, you from Visual Studio go open->web site.
I hands down prefer web applications, but they are MUCH harder to deploy a small change, since as noted, you have to re-publish the whole site.
However, the two different choices would thus explain the "difference" and as to why the other site don't experience the delay as much as you are. However, usually on first load - there can be a one time delay after a re-publish. And this quite much means the site is down for this time to re-publish.
Also, do keep in mind that if you do modify some files (such as web config), then this WILL cause the app-pool to re-start. (and if you not using sql server sessions, but in-memory sessions - they get blown out when you do this).
It also somewhat possible that the server with one user has more memory, more CPU and a much lighter load - so the reduced delay after making changes might well be the light load on that server.
However, the above two different publishing models and types of asp.net sites would be the first thing or at least the first issue to be aware of.
First, you need to determine if it is a website or web application project (https://learn.microsoft.com/en-us/previous-versions/aspnet/dd547590(v=vs.110)?redirectedfrom=MSDN#Anchor_1). Default for web application is rebuild for single page changes while default for website does not force recompilation except if special folders or files are modified. You may check to see if any settings for the app pool differ-- in particular "Disable Overlapping Recycle". You may also check the web.config as there may be a setting that is forcing rebuild. You want also want to look at Explicit Complication/pre-compilation option.
You may want to reference the following resources: https://learn.microsoft.com/en-us/previous-versions/ms178473(v=vs.140)?redirectedfrom=MSDN
https://learn.microsoft.com/en-us/aspnet/web-forms/overview/older-versions-getting-started/deploying-web-site-projects/determining-what-files-need-to-be-deployed-cs
https://learn.microsoft.com/en-us/previous-versions/aspnet/dd547590(v=vs.110)?redirectedfrom=MSDN#Anchor_1
Optimization setting
https://learn.microsoft.com/en-us/archive/blogs/davidebb/a-new-flag-to-optimize-asp-net-compilation-behavior
We recently migrated a large ASP. website from framework 1.1 to framework 3.5 and in the process also migrated from a website to a web application.
On the surface everything seemed to work fine, but now we are discovering that none of the "pages" are doing what they used to.
The site is made up of one default.aspx page that loads all the "pages" as user controls. (I am guessing this was to achieve the same effect as having a master page before master pages were invented.)
I think we missed a trick (or twelve) during the migration. What are the big stumbling blocks that other people have experienced
Update
We managed to find the problem that was making our pages stop working, but can not figure out why: When we cleaned up the code of the main page, we added whitespace (a newline) between the open and closing tags of the control that all the other "page" user controls get loaded into. Once we removed the newline everything started working again. Can anyone explain this?
I have experienced problems during manual copying etc. that has lost the connection between the GUI controls and the event-methods in the code behind. There are differences between the different versions of ASP.NET on how the event handling is coupled, and there are even more than one way of doing it (automatic based on names or explicit in code), and this is easy to mess up when changing from one "standard" to another, which is what you do converting to a differen version of .NET. It is also an additional source of confusion for Visual Studio when you also converted from Web Site to Web Application.
I am guessing that the trick was just to do some editing in Visual Studio, and VS might have automagically re-attached event handlers etc.
One things you should know is that if your new server is 64 bit. There is a chance that the controls on the page will be loaded concurrently with the page. In a sense there will be a lot of timing issues. If you are not using 64 bit server however this is not relevant.
This may sound a bit general, but I have a startup that is working on an ASP.NET (greenfield) suite of software applications. We are aiming to spend a substantial amount of time in the architecture phase to develop a strong foundation for our software. I was wondering if anyone has any advice, anything we should focus on or any suggestions for areas we should focus on to build a better suite.
Some things we are focusing on right now:
1. Session state requirements - should sessions be sticky or should we take server clustering session migration into account.
2. User login authentication - what are the major concerns in this space - LDAP, AD, custom SQL authentication systems etc.
3. The DAL - ORM vs Stored Proc
4. Integrating multiple ASP.NET applications in a single software suite. How it should look/feel. How it should be architected, etc.
I would appreciate any advice from any architects out there that have built similar systems from the ground up.
I know there are lots of solutions to session, but if you can create your framework to be session-free, you will avoid a lot of potential headaches. (There are lots of session-free options, but an obvious one is a hidden form field, somewhat like ViewState.)
Just some quick notes. I can't get too detailed since we went through this exercise where I worked last year - and I don't work there any more!
Start from the beginning using Enterprise Library, especially the Logging and Exception Handling application blocks. I've also found their Unity dependency injection library to be very useful.
Consider using Visual Studio Team Foundation Server. It's not just for source control, but can create you a complete continuous integration solution, complete with integrated bug tracking, code quality tracking, etc. If you've got the time and people, it's well worth a man-month to learn how to do an initial deployment.
You may want to buy one or more licenses of one of the Visual Studio Team System editions. You don't need these versions in order to use TFS, but they work well with it.
Consider globalization right from the start. Same with customization, if your suite will run on customer premises and be customizable by them.
You haven't said how large your team is, or is expected to be. If it's large enough, you'll want to spend at least a man-week learning a bit about what's available to you in terms of Visual Studio Extensibility. Your developers (and maybe also your QA folks) will all but live in Visual Studio, so the ability to customize it to meet your needs can be a big win. Whether it's just some macros and maybe some customized project or item templates, or whether you want to do add-ins or more, Visual Studio is very extensible.
Be certain to use WCF for any web services work. The older ASMX web service technology is now considered by Microsoft to be "legacy software".
Finally, be sure to find out whether you qualify for BizSpark, "A program that provides Software, Support and Visibility for Software Startups." And does so almost for free.
I saw a demo of Silverlight 3 at the PhillyDotNet User Group last night - WOW. Wow for business applications, not graphic applications. There is a learning curve, but you get a lot for it. For example, the demo showed a grid being bound to a table without needing to write any code.
Right out of the box you had sorting, editing, paging, etc. But it wasn't the lame stuff you normally get and then have to rework. For example the paging was smart enough to write the sql that would only bring back the 20 rows you needed for the page.
The demo continued with him putting a detail form on the page for editing. Again no code, but it was smart enough to know that it had the same datasource as the grid on the page. So as you were moving row to row on the grid - the detail form was showing the current row (and it was very fast).
Both the grid and the detail form were editable and as you changed a field in one the other would reflect the new value. The editing was smart enough to validate the field on its own. So you couldn't put a letter in a field that was an integer type, etc. It also limited the number of characters that could be entered based on the column size found in the database. All the date fields on the detail form automatically had a calendar next to them. You get the idea - no coding for any of this.
If this weren't enough, it can be used to build occasionally connected applications. So he showed how he updated a few records on a few different pages, had the option to revert back a field later (ctrl-Z), and then at the end submitted all the changed records to be saved.
Also, they said it works with Linq2SQL and the entity fraimwork.
So if I were building a new product now, I would really look into this as a way of differentiating my product. And I suspect that if you don't do it with Silverlight now, you will be rewriting it in a few years anyway.
Here is a link to a demo (not the one I saw.)
Some general thoughts. If you'd like me to expound on any of these, let me know.
Inheriting from a custom subclass of
Page instead of Page itself is a
great way to share functionality
across your site.
Nested MasterPages are good.
Charting: I've tried DevExpress,
Syncfusion, and MSChart control and
all have their own issues.
The built-in forms authentication is
pretty good. Building a site that
allows both integrated authentication
and forms authentication is tricky
but can be done.
I've tried using cross page postbacks
and I'm still not sure if I like
them.
Localization takes a lot of time
Come up with a good structure for your App_Themes and css.
Use Elmah to track unhandled exceptions
I'm trying to use the asp.net (3.5) built in user management framework but I'm not 100% sure how to do this on godaddy. Google didn't help much, anyone have experience with this?
You can roll your own or find one. You cannot run the Asp.net configuration tool directly against your GoDaddy account. (If you notice, it's just another asp.net website runing in another dev web server via Visual Studio).
You can use the System.Web.Security.Membership and Roles static classes in the Membership Provider to hook into it. This is very easy to do. Membership.GetUsers(), etc.
You can also use the stored procs to manually add/remove users and roles.
-Nathan
Go to your hosting control center
in menu Content on top, go to IIS Management,
there will be list of web folder,
on top of the list you can see asp.net runtime versions and (modify) link in brackets, click on it. There you'll see if you are using asp.net 3.5.
I have also had this problem. About a year ago. So I am curious to know what the solution might be, if there is one! I was told by Go Daddy, back then, that they had ASP.net admin stuff "locked down" pretty tight. I went back and forth with their help people, who had to actually escalate it - because the general help team didnt understand what I was asking. What I ultimately did was I canceled my hosting service (they did give me a refund for unused time!) and I went over to a different host. Hope this helps and I will be listening carefully to responses as I am curious to see if they changed OR if someone has a workaround.
To get the tables that the membership provider uses, look in %WINDIR\Microsoft.NET\Framework\v2.0.50727. That is where the SQL statements used by the wizard are located. Also, check out:
http://www.asp.net/Learn/Security/tutorial-04-vb.aspx
for a more thorough explaination of how memberships tables are set up. You can do all the same work that the admin tool does, just not in a GUI format.
I have been programming in php for a while, and recently I started a new job ago where I am now programming in c#/asp.net.
While asp has decent performance when deployed, there is one thing that has been bugging me for the past few months. After any code change it takes about 30 seconds for the page to reload for testing.
I guess it is doing the JIT compiling or something. But it can be REALLY frustrating, especially if I am concentrating, and want to test out several incremental changes as quickly as possible, only to have to stare at a blank page for 30 seconds.
Does anyone have any tips to speed this process up?
In Visual studio 2005 every reference you add adds a .refresh file that makes sure the reference did not change since last time and if so brings the new version - if your references stay the same, you can just remove it!
also see here for more tips for VS 2005
Two things I have found:
Try alternating between the "User Visual Studio Development Server" and "Local IIS Server" in your project properties / Web tab. Depending on your project, one may be faster to start and attach to than the other.
If you have projects in your solution, such as CLR-based SQL procedures, they take a few seconds to deploy to the SQL server. If you can afford to remember to turn them back on, or make a separate project config, disable them in the build so they do not get deployed every time you press F5.
Doing those cut my "F5 to live" time from about 20 seconds to 4.
I guess that can be frustrating coming from PHP.
Thirty seconds sounds far too long though. Ensure the basics like free ram etc..
A couple of tips.
1. You do not have to run the debugger in order to run the site. Once you have the site up with the built in VS web server or IIS, you can make your code changes, build and just refresh the page in your browser. No need to hit play and have VS start the whole debug process. If you actually want to debug though, you don't have a choice.
2. Changes to an aspx page do not require a rebuild. I make changes and simply refresh the page to see the result instantly.
Check out the web tab in the project settings to configure how you want VS to handle serving the site. There are some options in there to hopefully help you suite it to your style. ex. I don't let VS launch a browser for me whenever I want to debug. I set the option for it to just wait for a request. Then I can just use the browser of my choice to get started.
Good luck
I feel your pain.
Personnaly I like the ASP.NET website project better for speed of developing.
I don't know if you have that possibility though..
In visual studio do file->new website.
For this project type you don't need a rebuild all the time and you can just refresh a page in your browser when you have changed it. (no rebuild/debug necessary)
I've had similar experiences, it can be slow to recompile at times, but varies based on where and what code is being changed - ie if it is app_code or just page specific.
What sort of hardware are you running on? VS can be a memory hog, and anything less than 2GB seems to make it slow.
Our website has a very long load time due to actions which only occur during the Application Start phase (when the ASP worker process starts). In particular loading commonly used objects from a database into memory was causing a significant delay. We found that using compilation symbols to disable some features when debugging eg security and user roles, helped a lot.