I have several projects I work on concurrently, and have files open for each one. However, having a separate window open for every project is undesirable (mainly because when I Cmd-Tab/Alt-Tab between windows there are 5 different Atom windows instead of 1 and I have to squint and try to identify which one is the project I want).
I know I can open project folders in a single window, but then the tabs for all open files are all open together, which presents an even bigger problem for finding what I want, especially if each project has 4-5 files open.
Is there a way to
have a single Atom window
display multiple projects
display only the open tabs/files for one project at a time, swapping when I select a different project
I found a package that does essentially this: project-plus.
(Tabbing between projects could be improved, but it solves the pain points I mentioned.)
Related
I have a project that I've been working on for several months without a problem. Yesterday I tried to profile a bit of code using the raster package that was taking a very long time to run. I left it running overnight and found RStudio unresponsive in the morning. Now when I open that project, I can't do anything except to force quit RStudio. Other projects appear to work fine.
I suspect something bad is stored in the file(s) that remembers where I was. Is there one or more that I can delete and regain control of the project. Candidates in the project folder would seem to be one or more items in the .Rproj.user directory.
I found a tip on the RStudio website. In a terminal, navigate to the project directory and rename .Rproj.user to something different. I used this command - mv .Rproj.user .Rproj.user_old. This keeps the user-specific information around in case you want to go back to it.
I am a C# winforms programmer, not used to ASP.Net.
As a winforms programmer I build regularly to detect syntax errors.
Recently I opened a Kentico website in Visual Studio and to my surprise found that there were build errors.
Does this matter?
My instinct is to go about correcting the site until it builds. This is a side track from what I set out to do.
If you are attempting to build any kind of quality into your project/software, then yes, it does matter if it builds.
Regarding Kentico and build times, if you're using a website vs. a web project, yes the build times are typically longer and range anywhere from a few minutes to I've seen upwards of an hour. The build times depend greatly on the machine building it as well. So if your machine has a Celeron processor, with 1GB of RAM and a 5400 RPM drive, you're going to take longer to build than a machine with an i7 processor, 16GB of RAM and a solid state hard drive that can read/write 500+ MB/s. Also keep in mind Kentico out of the box has over 9000 system files in it so as a website, it will take some time to build.
One of the first things I check when a site doesn't build is to ensure all the referenced DLLs are in the website/project. If not, this will cause several errors and is usually a very simple fix. If you have any kind of errors from code which resides in the /App_Code directory, your site will NOT run at all when you publish it. If you have errors within any other directory, the site will run BUT wherever those code files are referenced on the website, will display errors. So in your instance if you have webpart files in the /CMSWebparts/OurCompany folder, if those webparts are placed on pages within the website, those pages will error out even though the rest of the site is running.
In my opinion, just fix the errors and be done with them. Then check the code into a version control system to keep track of the changes.
Does this matter?
It depends on what you are trying to achieve with your website. If you want to make it available to the public then building is definitely something you should consider as top priority. If on the other hand you want to have the source code open in Visual Studio on your local machine, just for reading purposes, then building is not necessary.
I'm currently using VS Community 2013 but I've seen this behaviour in previous versions of VS.
Scenario: I have previously saved and closed a solution whilst it has several tabs open. I then re-open the solution. The open tabs reload, but (as far as I can tell randomly) one or more of the aspx files that were open when I last saved and closed the solution, are recreated as a blank file with the extension aspx:1 or aspx:2.
Closing the blank file & reopening that file from the Solution Explorer restores the correct version of the file. No work is lost, so I admit this is an irritation rather than a crisis.
What's going on, and more importantly any idea how I can make it stop? I have got the Preview Tab functionality (Options >> Environment >> Tabs and Windows) turned off. Thanks
http://ambracode.com/index/show/161001
it says there:
"It's the naming convention for Visual Studio when the window is cloned. Sometimes, however, Visual Studio just gets confused and names it that way."
Every time I nav back to the file tree browser in Xcode 4, whether from debugging, examining the build log, etc., it closes my main "yellow" folder which contains my project sources. Thus I have to dig through multiple levels of folders to get back to the files I was just editing, e.g. before the build. It also keeps auto-expanding the 'blue' folders which are references to trees that I don't need to browse and would prefer to keep closed.
Apple is ignoring its own UI guidelines which say that STABILITY is the primary feature of a good UI. Xcode 4 is so buggy and the UX is so cumbersome it's nearly a laugh.
How can I get Xcode 4.2.1 on OS X 10.7.3 to keep my open folders open, and closed folders closed, in the file tree browser?!
I have a problem debugging a web forms application that is configured to use IIS for debugging, under Windows 7 and Visual Studio 2010. An example has just occurred, where I make a change to the code behind for a web form, save, and apparently rebuild before starting the app using F5.
The app starts, and I get an error message trying to do something in the app. I tell the debugger to break when an exception is thrown and try my task again, only to be told
The source file is different from when the module was built.
where the module is C:\Windows\Microsoft.NET\Framework64\v2.0.50727\Temporary ASP.NET Files\root\9d7b45ca\11a98b19\assembly\dl3\5e6cf0b2\636409d4_dfeecb01\PerfixEMS_Admin.DLL
The physical folder for my test web site is set to the web application project's source folder, so I have always assumed that IIS will look in the bin folder for required assemblies, and these will be rebuilt as expected. Why is this not happening?
Cleaning the solution usually works for me.
Update
Given the high number (320) of projects I understand why Clean and Build won't work for you. You should however try it at least once to see if fixes things.
If it does fix your problem but doesn't last you'll need to do one of two things.
Clean just the one file
Delete the offending temp file. You probably won't be able to do this because with VS running since it may have a lock on the DLL. You may also have to stop IIS. You can use Process Explorer to look for the processes that have a lock.
Use a custom solution
Its unlikely that you're going to be modifing all 320 projects at the same time. Create a custom solution for just the projects you're working on. You'll still be able to step through any project you have the DLL and PDB for if you need to.
Which to do
Using a custom solution has its problems since you can no longer use project reference for projects not in your solution. This impacts your team's source control. You'll also have to make sure the DLL's and PDB's from outside your solution are in a stable location and you'll need a way to detect when thoes other projects have changes that you care about.
These problems can be overcome with a careful check-in process for Project changes and scripts that copy files and working with team members to figure out how to communicate changes.
On the other hand closing VS for every change or running Clean and build isn't really tennable either.
it may be a workaround, but I just need to see if it will work or not, then we may investigate more in the original case. but for now, try this:
1- publish this website to a different folder
2- open the newly published version from your preferred browser (ex: http://localhost/APP_NAME).
3- from VS, open "Debug" menu, choose "Attach to process..."
4- select the IIS worker process "w3wp.exe" and click "Attach".
(if you can't find it, make sure that the checkbox "show processes in all sessions" is checked)
5- start debugging your source code normally and let me know what happened, thanks.