Just started a new Web Site Application project, and just find it takes to long to open my webpage straight I build it. This is a brand new project which has just the minimum number of files, but there is other files in the folder which are not part of the project which are not included in my project.
Anyway I press build, build complete, try open the webpage i.e. http://unitedcms/default.aspx.
Need to wait like 1 min before it loads, after that initial load it loads instantly ofcourse im just wondering why that initial load takes so long ?
The reason for this is that IIS/Cassini compiles your project after every build. This compilation takes time to complete. Once compiled, IIS/Cassini stores them in cache. On subsequent requests, IIS/Cassini will not recompile the code but serve it from the cache.
That's the reason your first request is always slow.
Here is an example. Using notepad, edit your web.config file (just add an empty line or space). Save it. And then try to open your site again. It will take time to load. That's because IIS checks your web.config file's last modified time stamp and if it's newer than the one in cache, it will re-compile the code.
Hope this helps.
Related
i have a solution
it has 2 projects inside.
there are an exe and a website.
the issue occurred when clicking F5 to start the debug process.
when i have set the exe to the default StartUp project. The exe can run normally, and the break point can be reached correctly.
however, when i have set the website to the defualt StartUp project. The website can be launched, however the breakpoint cannot reach. also the version isn't the latest one, it looks like it is loading the last succeed version (no error and warning too)
I have to right click the website project and click start new instance in the Debug every time I have modified something!(which is very troublesome)
Thus, I want to know why my F5 isn't equal to the Start new instance, as it is working normally in the other solutions.
I fixed that but the below procedures after struggled from extra many clicks compiling experience.
the cause is that there is unknown reason that the build checkbox isn't checked in the configuration manager. simply check it and everything looks fine again...
hopefully it can save someone time who suffered from this issue in the future
I have two console application projects in a single solution and they are both configured to build to a common directory. The first app calls the second app via
Process proc = new Process();
proc.StartInfo.FileName = "myprocess.exe";
I can change my startup project and debug either one of them individually just fine, but I'm unable to step into the second project from the first project. When I look in build\debug I see the .pdb files for both apps and I know the second app is running completely through its routines. I just can't step into it. I've looked at Attach to Process and Debug:Location but haven't been able to find a solution yet. I've even tried putting them in different VS solutions, but to no avail.
So I need a way to step from the first project into the second project while debugging. Any suggestions would be appreciated.
Thank you.
You can use
Debugger.Launch();
which will bring up the dialog asking if you want to attach a debugger. You won't be able to 'step in' from the existing debugging session since it's attached to a different process.
First of all, I'm not using Core Data, I'm using SQLite only.
I save the data in the table and then query them by opening the app and looking at the data using SQLiteStudio. I even create a LOG to check that the data is saved, and yes, it is saved.
But when I STOP and run the simulator again to consult, there is no more data!
Is Xcode overwriting the database every time? Or is something else happening that is outside my limited knowledge?
Without knowing more about how your application is setup, how you've got your app configured to build, or how it operates on the SQLite DB file in question I'll only be able to offer some pointers in things you can go check out about your code and build configuration that may be the source of your phantom deletions. Of course, if you have other info to provide, I'd be happy to edit my answer!
Case 1: 'Create DB' always running?
One thing that may be tripping your app up is what happens leading up to the decision to create a new SQLite DB file or look/open an existing file. If the code creating an empty DB is always running, then each time your app starts, your old DB file is getting overwritten with a blank DB.
Case 2: Using a 'starter' or 'template' empty database?
Sometimes developers may provide a blank database that contains the initial database schema (the general tables and structure) as well as some default or sample data. If your app does this, perhaps the logic leading up to the decision to apply that default database is accidentally always being triggered? If so, use of NSUserDefaults to record a boolean indicating the DB was successfully created may be an avenue to use to skip past the 'Load my starter DB' code. Alternatively, you could check for the existence of your DB file, or see if the contents of a specific table are different from the template data, etc.
Case 3: Different Behavior between 'Build & Run' vs. 'Run Without Building'
There's a not-so-well-known option in the Product > Perform Action menu labelled 'Run without Building' that will essentially kickoff another Debug session using the version of the application you just finished running in the Simulator or on Device. When you use this option do you see any different behavior with your database or is it still blank?
Case 4: Different Behavior when run directly in Simulator outside of an Xcode debugging session?
Part of the 'Run' operation is a build phase which may trigger the 'Copy Resources' phase even if your app hasn't changed since the last execution (as you suggest is the case in your question). If you are providing a stock 'default' or 'template' DB file and your app is simply opening and editing that 'template' during the first execution of your app, then Xcode may be replacing it with a clean copy on the subsequent 'Run' operations where 'Copy Resources' is happening. A way to test this avenue:
Build and Run your app to the simulator using Xcode like normal.
Perform some operations that would result in the creation or editing of data in your app's database.
Click the stop button in Xcode to return to the Simulator home screen.
Double-click the home button on the simulator (or if there is no home button, press CMD+SHIFT+H twice to bring up the multitasking bar and force-quit out of your application.
Check and see if your DB file has data in it.
If no data, then there is an issue persisting your changes into the database and we need to get that problem solved first. Otherwise:
Relaunch your app directly from iOS Simulator and perform different operations that would result in more or different changes to the database.
Click on the home button to return to the iOS Home Screen.
Force-quit your appellation as was done in Step 4.
Check and see if your DB file data has changed (but still has data) or has blanked out.
Finally, make sure you are following Apple's guidance about where to store user-data, if you are inadvertently storing something in an incorrect file path doesn't typically result in blanking of data, it may be prohibiting writing of data which could be interpreted as your data getting overwritten especially if you are interrogating it while it still is residing in an in-memory process. There's some really useful guidance about file paths in the Table 1-1: (http://developer.apple.com/library/ios/#documentation/FileManagement/Conceptual/FileSystemProgrammingGUide/FileSystemOverview/FileSystemOverview.html)
Locating your Simulator App on your Mac's Hard Drive
To be thorough (and you may already know about this!), iOS Simulator applications are stored on your Mac's hard drive just like other files on your machine. Their organization mimics that of a physical iOS device. To get to your App and its data:
Open a new Finder window.
Press CMD+SHIFT+G or choose 'Go to Folder' from the 'Go' menu.
Paste the following into the 'Go to Folder' box then click 'Go': ~/Library/Application Support/iPhone Simulator/
Select the folder that matches the iOS version of the simulator you built to.
Click on Appications.
You'll then be presented with zero or more folders, each folder that appears will have a string of digits separated by hyphens. Navigate through this list until you find the one containing your app. You can then browse, and copy data out of this folder to somewhere to be examined by other tools on your Mac.
I am using LESS with my node.js setup on my Windows dev machine. I've noticed that changes made to my .less file do not cause my .css file to be regenerated. If I want to see these changes, I am forced to delete the .css file. This will be regenerated the next time a request is made.
I was under the impression that the .css file was supposed to be regenerated after every change to the .less file (comparing the last modified date). I was curious if this was an issue specific to Windows.
Furthermore, I've noticed that the first request for a .css file forces it to be generated, but a 404 will be returned to the browser (aka no styles show up). Subsequent requests will find the .css file. I want to avoid ruining the first, unlucky user's experience.
Sounds to me like you are using express and/or connect middleware and you have your static handler before your compiler handler in the app configuration.
Switch them around.
The compiler will then get a chance to handle the request, seeing the file needs (re)compilation and once that is done the static handler kicks in and serves it.
app.use(express.compiler({ src: __dirname + '/public', enable: ['less'] }));
app.use(express.static(__dirname + '/public'));
I guess we can add this question to the list. Basically It's been taking me twice the time to try something out because everytime I try to debug my app I have to wait about a minute to lauch the app. There are 3 files in order that it complains about.
Resources file (.g)
Program Debug Database
DLL (.dll)
I tried removing the first two, but then it complains about the DLL file. Strangely enough I have never encountered this and I've been using the the WP7 emulator in VS2010 for about a year. Any ideas? Is there possibly a setting or cache that can be deactivated?
Basically when you add images to your project, by default they are added as a resource. By doing this everytime you try to build the project the images are saved in the dll file thus the long wait time. I set 95% of my images to content and have not had the issue since.