I've noticed that when using the summary field as defined here that the summary nicely shows up in the package management within Visual Studio but they don't show up when looking directly at the package repositories listed below. Why is this? Since it seems to be all of these places not some honor it and some don't there must be a reason.
http://www.nuget.org/packages
our private proget repository
(edit: appears chocolatey prepends the summary to the description)
Related
I'm trying to generate documentation in c++ project (VS 2022 Community) using xml-tags in comments like <summary>, <returns> and so on. I was searching project setting, configured output file and rebuild project. But result was zero. I can't find output file. Was it generated at all? Can't understand where he is. I know there are also several programs/plug-ins making doc, but I want to try embeed services. Output file setting is $(OutDir)$(TargetName).xml
SOLVED! =)
So, to generate documentaion you need to enable option Create XML-documentaion file at Project->Settings->C/C++
Default setting of files path are working. Another options are in Project->Settings->XML-documentation generation
Ah... It was difficult to find. No link in official docs to this theme)
I've used Visual Lint (as a frontend for PC-lint) in the past and somehow configured it to use a different options.lnt file for different projects. My recollection, which might be incorrect, is that it was configured to automatically pick up anything called "options.lnt" in any project's directory - i.e. I didn't have to configure this for each project individually.
So for example I might have two projects, ProjX and ProjY, and I might have different options.lnt files in each of them:
C:\MyProjects\ProjX\options.lnt
C:\MyProjects\ProjY\options.lnt
Possibly those might refer to certain sets of general options stored in other files; for example I have C:\MyProjects\Lint\options.lnt for very general things, and then more specific options files for things related to certain packages; for example I have C:\MyProjects\Lint\options_boost.lnt for use by projects that use Boost. So if ProjX uses Boost, C:\MyProjects\ProjX\options.lnt will contain (at least) the lines:
C:\MyProjects\Lint\options.lnt
C:\MyProjects\Lint\options_boost.lnt
Whereas perhaps ProjY doesn't use Boost, and so its options.lnt would have the "general" line, but not the Boost-specific line.
This was all working fine, but I've migrated to a new computer, and I can't seem to get it working again. When I run Visual Lint against ProjX, it shows messages that should be suppressed by (for example) entries in C:\MyProjects\Lint\options_boost.lnt.
I have gone into Visual Lint's "Tools / Options", and under the "Analysis" tab, I have set "Preferred Analysis method" to "Per project". I have the Professional edition, which I believe is required for this functionality. I am using version 5 (whereas the previous machine, on which this was working, was version 4).
Am I perhaps missing some additional configuration I need to set up in order to get Visual Lint to pay attention to the project's options file?
Answering my own question:
In Visual Lint, go to Tools / Options / PC-lint. In there, there's a "Configuration" field, containing the name of a *.lnt file (like C:\Lint\std.lnt) that applies to anything you do in PC-lint via Visual Lint. Edit that file to contain the line:
options.lnt
Without specifying a full path. That seems to make it pick up the copy of options.lnt from the project's directory, and that file can then contain the more specific lines as shown in the question, such as:
C:\MyProjects\Lint\options.lnt
C:\MyProjects\Lint\options_boost.lnt
the system options shows other than english on the SAS product, due to which some of the properties and also the help manual is not in english, how is it possible to change it? or do I have to install the SAS again?
As long as you installed the correct language(s), it's possible to run SAS in different languages. However, if you only installed one language, it will be sufficiently complicated that I would recommend an update installation (which is not a full reinstall).
This SAS technical support note covers this in some detail; it also recommends an update installation if you didn't install the language originally.
What you can do is look at the SASFoundation folder in your install, usually one more folder deep (the version), and then look at the nls folder. nls refers to language support, and it should have one folder for each language installed, including Unicode support and DBCS support. \nls\en will exist if you installed English.
If that's the case, you can edit your sasv9.cfg to point to the config file you want to use - ie, the \nls\en config file. It probably points to whatever you currently are running.
You also can on the fly run one or the other simply by including in the shortcut or launch program the -config option pointing to the config file you want.
I have a package I want to install. I would like the files to end up in a different directory than the installation wizard choses for them.
For example, my Sitecore copy is running at C:\SiteCore\website
The module added files to C:\SiteCore\website\Console
I would like the files to ultimately live at C:\SiteCore\website\sitecore_modules\Console
I am using Sitecore 6.5 rev 111230, but we are planning to upgrade very soon. I would like for my installed packages to migrate seamlessly once we have upgraded. For reference, the package I want to install at the moment is the Sitecore Powershell Extensions. Although, I would prefer to apply a similar method to any future packages that I install.
Is there a secret switch in the package installation process to allow me to do this? Can I do it from the package installation wizard? Is there another way to install packages?
I'm assuming I can't just change the package path and expect everything to keep working. Do I have to update a configuration somewhere (a file or inside the Sitecore CMS GUI) to make the package recognize the new file locations?
The module creator defines where files exist. If you move them you run the risk of something not working. The best idea is to ask the creator on the Marketplace page of the module.
There is no turn-key way to change this.
I guess you cand take the code from MarketPlace and you can modify it.
I don't know how exactly is the licenses with MarketPlace modules, but I think people can modify others code.
Please check on code and also on items, maybe on some fields are values for folder path.
I discovered a way to accomplish this, but it can be quite involved or even impossible, depending on the complexity and size of the package.
First of all, I did take the question to the module creator and had a very helpful and informative conversation with the creator. So thanks for that suggestion - they may even move the install location in a future release, based on my request.
The workaround is to first install the package on a system as normal. Then you figure out everything that comes with the package. For files, this is easy if your Sitecore root is under source control. For items, this is really complicated. You can search for the installed items by owner, if you had the foresight to create & use a unique user for the package installation. Or you can check the untyped files in the package that are essentially xml based item manifests.
Once you have a detailed list, you make the desired modifications to the locations. Then you recreate the package yourself using the Sitecore package designer.
This works for simple packages - I did it to one small package that I hope to get up on the Sitecore marketplace as shared source soon. And by small, I mean it was 2 files and 3 items. The package that prompted me to ask this question would not cooperate with this workaround. The included .dll had some assumptions about the file structure hard-coded into it.
The workaround I took for the more complex package was really quite basic: I just created a new source-code external to the required path. That let me wrap everything up neatly without getting medieval on the package files.
Thanks for both your answers, a very fine +1 to you.
I am new to Visual Stuido and I want to know how to organize the dependencies of a project in Visual Studio 2010 C++ (Express Edition) best.
The main problem is the following:
A project P requires lib L, so I add dependecy L to P. L is somewhere located at my system. I submit P to our version control. My colleague checks P out, but the configuration of P does not fit to his system (L is located somewhere else at his system). So he adjusts the configuration and submits the changes to P. I check P out and now it does not fit to my system.
I come from Java and Eclipse. In Eclipse you can set a variable globally for the whole IDE f.e. PATH_TO_L. In the project configuration the dependency is now variable PATH_TO_L and not anymore a path. So my colleague and I can use the exact same sources including the project configuration. All we have to do is to set both the variable PATH_TO_L. Nice.
Even nicer is Maven. So you do not have to care about copying the right dependencies to the right locations, because Maven does all the work for you.
I searched a little bit for a solution. One possible solution would be to use Property Sheets and to add a template Property Sheet to our version control. But templates in version control are not comfortable to use and I would have to adjust the settings for every project. Not a global setting.
I tried to use system environment variables, but I think Visual Studio 2010 does not use them.
So here is the question. How do you organize your projects in Visual Studio 2010? Is there an ideal way? Is there something like Maven, or is there a possibilty to use an repository manager like nexus in Visual Studio?
You are on the right track, with the property sheets.
You could use a property sheet to reference a environment variable. An example is here.
I would add the Path of library to the user specific property file named Microsoft.Cpp.<platform>.user. As this is included by default. More information is here.
As soon as you get familiar with the property sheets it not as bad as it seems. I actually start to like the msbuild system. But I am not aware of anything like maven for msbuild.
Quite a lot of people are using meta-build systems, these days, such as CMake, SCons...
Amongst other useful features, you can set up some variables that you can later reuse, for example for paths. This way, your colleague and yourself will have the same CMake configuration, but with individualised paths.
And, as these scripts are simple text files, they play nicely with version control (much better than MSVC xml configuration)