It is quite annoying to see codelens reference between the field and field's attributes. It requires to add a lot of additional spaces around to make everything readable. Is it possible to display CodeLens reference above the attributes?
No, this is currently not possible.
If you'd like to see this, I suggest you give the product team a shout-out on the Visual Studio UserVoice and post back the link as a comment to this answer. I'd suggest not to move the code lens information, but to suggest the location to be made configurable :).
Though I can't disclose any details, I've seen your feedback before and I know it has been considered, but rejected.
This is an old question but as an update to #jessehouwing this is Visual Studio team answer:
Dear supporters for this suggestion
Thank you for your feedback on this idea.
We designed the Code Lens indicator to be as close to the actual
function declaration as possible, to allow you to make a better
cognitive connection with it. At one point during the development of
Code Lens, we actually tried locating it above the attributes as this
suggestion requests. It looked great in simple cases, but
unfortunately it started to feel “disconnected” from the declaration
when more attributes were added. It really looked strange at around
three attributes, but started feeling a bit odd around two.
Here’s a pathological “real world” case which illustrates this -
https://github.com/dotnet/roslyn/blob/master/src/VisualStudio/CSharp/Impl/CSharpPackage.cs#L26
Imagine the indicator above the attributes in this case.
For this reason, we’re declining this suggestion at present.
Thanks! Mark Wilson-Thomas Program Manager, Visual Studio Editor Team
So sadly it won't be fixed, but after reading the whole answer, I have to agree.
Ok, before I begin I realize that there is a lot of documentation on this subject but I have thus far failed to get even basic colourization working for VS2010.
My goal is to simply get to a point where I can open a document and everything is coloured red, from here I can implement the relevant parsing logic.
Here's what I have tried/found:
1) Downloaded all the relevent SDK's and such- Found the ook sample (http://code.msdn.microsoft.com/ookLanguage) - didn't build, didn't work.
2) Knowing almost nothing about MEF read through "Implementing a Language Service By Using the Managed Package Framework" - http://msdn.microsoft.com/en-us/library/bb166533(v=VS.100).aspx
This was pretty much a copy and paste of all the basic stuff here, and also updating some references which were out of date with the sample see: http://social.msdn.microsoft.com/Forums/en-US/vsx/thread/a310fe67-afd2-4592-b295-3fc86fec7996
Now, I have got to a point where when running the package MEF appears to have hooked up correctly (I know this because with the debugger open I can see that the packages initialize and FDoIdle methods are being hit).
When I open a file of the extension I have registered with the ProvideLanguageExtensionAttribute everything dies as if in an endless loop, yet no debug symbols hit (though they are loaded).
Looking at the ook sample and the MEF examples they seem to be totally different approaches to the same problem. In the ook sample there are notions of Clasifications and Completion controllers which aren't mentioned in the MEF example. Also, they don't seem to create a Package or Language service, so I have no idea how it should work?
With the MEF example, my assumption is that I need to hook into the "IScanner.ScanTokenAndProvideInfoAboutIt" to provide syntax highlighting? Which would be fine if I could ever hit this method.
So my first question I guess is which approach should I be taking here? Or do they both somehow tie together?
My second questions is, where can I find a basic fully working project that implements bog standard basic syntax highlighting and intellisense or VS2010?
Thirdly, in the MEF example when I created a Package there were a bunch of test projects created for me. I appears that the integration tests launch the VS2010 test rig somehow, but the test fails. It would be good to write my service with tests but I have no idea what/how I can test each interaction so any references to testing Language services would be helpful.
Finally, please throw any resource/book links my way that I may find useful.
Cheers, Chris.
N.B. Sorry I realize this is part question part rant, but I have never been so confused.
First, the package example is not using MEF. Essentially everyplace that you mention MEF in your question is not actually MEF, but the managed package framework (MPF), also colloquially called the managed language service (MLS). You'd know if your extension was using MEF by two things: the vsixmanifest lists your assembly as containing a MEF component, and you see [Export] and [Import] attributes in the code.
The easiest way to do this is to use MEF. Since you have the SDK installed, you also have a template for an editor classifier project (under C# (or VB)->Extensibility->Editor classifier in the New Project dialog). You can certainly do this with a language service/colorizer/package, but there will be significantly more code than the equivalent classifier.
The Ook solution is the sample for this and should work; if it doesn't build/work, then can you send me email (noahric at microsoft) with what errors you are seeing so I can email the owner of that sample?
In general, you should also read my answer for the question on "How can I write a plugin for VS2010 using MEF?". That has links to other resources that should help.
I see that I would benefit from using the class view in visual studio.
It would give me better overview over my classes, their methods and make it easier for me to see where and when to refactor my class. I assume that it would give me a better structure and enhance the readability of my code.
But....
I find it to awkward to use. I tried to get use it instead of solution explorer, It basically stranded before beginning. I find no similar functionality like "Track Active item in solution explorer".
Any idea on getting started on using the class view or that I just should forget it and stick to solution explorer and stay ignorant? ;)
Some years ago some people were sure that writing code will no longer exists and everything is going to be UML modeling, so I guess they were wrong.. its great power is initial model(as it name tells). Personally I found it slow clicking with the mouse and prefer writing my classes with coding..
The most important thing is to be productive. My advice is to try it (it helps in design), but if you don't feel comfortable with it, don't worry, a lof of good programmers don't know that it even exists :)
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
When you are starting a personal programming project, what is your first step? I'm trying to start a project thats just an idea at the moment. I get lots of these and I dive right into the code and after a while just completely lose interest and or just forget about the project.
When you are starting, what is your first step? do you plan out the project? make a diagram? write some code on paper? How do you start a project in a manner that you know you will succeed?
The only thing that works for me: Create the smallest possible implementation of it that's somehow usable and then use it.
From 7 Habits of Highly Effective People, Habit 2: Begin with the End In Mind.
With any project you need a clear goal, a point where you can say "I'm finished". A clear outcome will give you direction. Once you have that, you can start planning how to get there. The size and complexity of the project will determine how much detail your plan needs, but in general you'll want to feel your making progress against your plan quite regularly.
My next step is to sketch out a design of the modules that will be needed and the APIs between each module. If the APIs are clean then the modules are probably right. Then I start implementing the modules, testing as I go.
I spend a lot of time thinking about the various aspects of the project before I even touch a keyboard.
I go through what I've learnt from previous projects and write it down in various categories ('technical', 'promotion', etc)
Personal project or not, I always set up source code control. Git, Mercurial of Bazaar are examples of source code control tools that are not intrusive because you do not need to set up a master server. Just type a simple command to create the project, check your files in, commit. In the future, when you mess up one of your files, you will be able to 'undo'
I also set up a lightweight ticket system to keep track of 1.issues and 2.ideas
By "lightweight" I mean that if maintaining two text documents with these lists works for you, that's good enough.
Hope this helps.
I agree with the already given advice of:
Planning a minimal implementation that does something useful as a first complete release.
Have concrete goals about what you want to achieve to have something to compare your progress with.
I would also recommend beginning with a lightweight design of you overall architecture so you can have a roadmap of how to build your product.
I find it difficult to start building something when I don't have a clear idea about how it should look at least at a first level of decomposition. Think about what do you need besides functionality: high performance?, extensibility scenarios?, which ones?, usability goals?, high scalability?, ease of deployment and installability?, etc. Ask yourself: What components I will have to build in order to achieve those architectural qualities?.
And don't get me wrong, I'm a strong proponent of agile software development. You don't need to spend a lot of times designing your architecture (because it surely will have to evolve as you build and get feedback about what works and what doesn't), but having a blueprint of how to build your product based on its architecture should be useful in for planning your progress and setting realistic goals.
Define the goal for the project. Sounds like you are looking almost exclusively at the solution rather than the problem.
A program isn't useful to you or anyone else unless it addresses some problem. Writing code to get moving is great, but you appear to lose interest and focus after you start -- because you're looking at the code, not the problem.
Spend some time considering what led you to write this code. Ponder how other people might discover the same need, what path might take them to the same frustration you worked to solve.
Then, find some of those people and offer your (partial) solution, and you'll generate interest and suggestions among them all.
THAT will keep you going on your project. The fellow interest, the sharing, even the disagreements -- it's people who need software! Don't create solutions (software) looking for a problem (people). You started with YOU, with your need or desire, but focused on the code, and lost the impetus for the project.
Programming's a lot more fun when you're problem-solving. But you need to keep the problem in front of you. Sharing the problem builds community. That's what this is really all about, isn't it?
For my own personal projects I just dive right in. Of course, none of these have yet been sufficiently large as to require any sort of pre-planning. If this is going to be a serious project or a relatively large scale, it is always a good idea to flush out at least what each part of the program needs to do and a high level view of how they will do it.
Like the others, my personal projects always have:
A Final Goal
A Task List
Small usable units
Source control
As an additional motivator, I try to use a technology that I have never used before. Learning something new generally becomes the largest motivator for me.
Easy - don't start at all projects you're likely to lose interest in. Spend more time to make sure you want to commit yourself to an idea before beginning any work.
It depends on the project - how big is it?
If I'm writing the next Notepad clone I might just dive in, if I wanted to roll my own operating system it'd take a lot more non-coding work.
I like to do a lot of diagrams, the tool I use for most development is clean A4 paper and a pencil. Draw out the UI, workflow, basic classes, and how you're going to store any data - then the coding is just a computer readable way of writing what you drew already.
Source control le.g. SVN is a couple of keystrokes/clicks, so the overhead is low and the benefit is high, its handy to try stuff and just revert to an earlier state if they don't work.
Then just make the most basic protoype that will work - once something is actually going it is much easier to get enthused and add more. If it is overwhelming I'll find I think the problem is solved in my head, and thats enough.
First plan out the basic outline of the final application. Most important features, basic GUI, program flow, etc. Then refine that so that you don't take on too much at first, remove unnecessary features, and add what else you want in the first version. Then use that outline to start a task list to create the smallest possible working version of your application. Then it's much easier to add extra features and make it fully functioning.
I like Maximillian's answer.. to expand a little, my person projects are developed to solve something I'm working on already. So when I get tired of repeat work I'll prototype a solution. and then use it. If Its similar enough to one of my earlier projects I'll borrow as much code as I can and try to improve the level of my work, make it more professional.
Fusion's use of Source Control is important too. Takes 2 minutes to install SVN.
If you want to turn it into a public open source project, Producing Open Source Software is supposed to be a good read (available both online and in print).
If your personal project is similar to an existing open source project, you should consider contributing to that project instead. A couple of small contributions (bug fixes etc.) are
more valuable than a half finished project.
All of the above, but start to cement the plan in place.....
Go for some tools
SmartSheet - even if you are working on your own you should set out some stages and dates
yEd - and Graphity from www.yworks.com
Is there an easy way to produce MSDN-style documentation from the Visual Studio XML output?
I'm not patient enough to set up a good xslt for it because I know I'm not the first person to cross this bridge.
Also, I tried setting up sandcastle recently, but it really made my eyes cross. Either I was missing something important in the process or it is just way too involved.
I know somebody out there has a really nice dead-simple solution.
I'm reiterating here because I think my formatting made that paragraph non-inviting to read:
I gave sandcastle a try but had a really hard time getting it set up.
What I really have in mind is something much simpler.
That is, unless I just don't understand the sandcastle process. It seemed like an awful lot of extra baggage to me just to produce something nice for the testers to work with.
You're looking for Sandcastle
Project Page: Sandcastle Releases
Blog: Sandcastle Blog
NDoc Code Documentation Generator for .NET used to be the tool of choice, but support has all but stopped.
Have a look at Sandcastle, which does exactly that. It's also one of the more simpler solutions out there, and it's more or less the tool of choice, so in the long run, maybe we could help you to set up Sandcastle if you specify what issues you encountered during setup?
You should also use the Sandcastle Help File Builder. It provides you with a ndoc like GUI for generating help files so you don't have to do anything from a command prompt.
Welcome to the Sandcastle Help File Builder Project
I've just set up Sandcastle again. Try installing it (the May 2008 release) and search for SandcastleGui.exe or something similar (it's in the examples folder or so).
Click Add Assembly and add your Assembly or Assemblies, add any .xml Documentation files (the ones generated by the compiler if you enabled that option) and then Build.
It will take some time, but the result will be worth the effort. It will actually look up stuff from MSDN, so your resulting documentation will also have the Class Inheritance all the way down to System.Object with links to MSDN and stuff.
Sandcastle seems a bit complicated at first, especially when you want to use it in an automated build, but I am absolutely sure it will be worth the effort.
Also have a look at Sandcastle Help File Builder, this is a somewhat more advanced GUI for it.
Follow this simple 5 step article and you are pretty much done. As a bonus you can use H2Viewer to view Html Help 2.x files.
I use NDoc3