I have recently started using CAML.NET IntelliSense for SharePoint with Visual Studio 2008; which works great; however whenever I create a new project using STSDev 2008 (and thus generate feature.xml and WebParts.xml) the default schemas include the CAML.NET IntelliSense and the built-in (relatively incomplete) schemas:
caml.xsd
wss.xsd
coredefinitions.xsd
camlview.xsd
All found in web server extensions\12\TEMPLATE\XML. The existence of both of these schemas for the file causes a large number of warnings, notifying me that a specific schema entry is already declared in one of the above files. Disabling them for each file individually works great, however in a SharePoint solution whit 40 or 50 XML files this quickly becomes laborious.
Is it possible to disable these built-in Schemas, selecting "Do not use selected schemas" does not work for future XML files only the current one?
Well, if you really don't want them - you could remove the schemas from the xsd path (%VsInstallDir%\xml\Schemas) - and perhaps disable download (Options->TextEditor->Xml->Miscellaneous). My machine isn't in a suitable state to try it, but it should work in theory...
Related
I'm currently working within a monolithic solution that is a conglomeration of several smaller projects and the result of many developers efforts. However, one of these efforts was not the creation of a standards document regarding naming practices for test classes. As such I have over 1500 individual test classes that may have a suffix of "Test", "Tester", or "Tests".
Is there a good way to batch rename all the *[Test|Tester].cs files within our solution to *Tests.cs taking into account the preexisting TFS and project file structure?
The solution that seemed to work for me was to do a Find & Replace via a regular expression across targeted test projects within my solution.
In the standared Visual Studio Find and Replace Dialog
I searched for public\W+class\W+([a-zA-Z0-9-_]+)Test(er)?\b
and replaced with the captured group of public class $1Tests
within all files matching *Test.cs;*Tester.cs
Importantly, and for reasons unknown to me, if I didn't check the "Keep modified files open after Replace All" the find and replace would fail
eg:
Once the find and replace operation was completed I used Resharper's Move Types Into Matching Files refactor function on the test packages in order to update references in both TFS and various project files.
Use a local workspace and your bulk renaming tool of choice. It doesn't have to be within Visual Studio. A local workspace will allow changes to the structure of the project to be made from any tool and still "noticed" by the pending changes window or tf.exe.
You'll still have to update the *.*proj files to take into account that the files have been renamed, of course.
I am a Visual Studio noob. My background is more Unix-related and mostly used to building things via scons or make. I don't even have much Eclipse experience.
Anyway, I am frustrated how it seems very difficult to move files between projects in VS. (I am running Visual Studio 2013). For example, suppose I have a ProjectXRel (release) and I want a ProjectXDev (development). I want them both to be runnable, and the dev version might have just a few editing changes that differ it from the rel version.
The intuitive thought is to just copy the files from ProjectXRel to create ProjectXDev, but VS seems to fight me on that (it wants to rename all the namespaces to the title of the project).
Also, some of the files, like .cs files derived from .dbml via OR designer, seem uncopyable, and rely on one replicating the process of using the utility to having valid files. I'm used to a project being defined by its files, but that's not really the case in VS. Instead it seems defined by process steps used to create and organize the files.
Also, do serious developers just use command line calls and powershell? That's seems harder, but at least you know what the %#$$# is going on.....
So, the basic question is, how does one replicate an existing project to produce a similar one for development purposes? (I know source control such as git could help with that, but that's not an option for this situation.)
Thanks!
You should be using the same project for both Development and Release.
The things that are different between Development and Release should be stored in a config file (web.config or app.config, depending on what type of project).
You should then be using Configuration Transformations to transform that .config file into Development or Release.
In Visual Studio, right click on the project and click Add New Item, select "Application Configuration File".
In this file you can put connection strings or key/value pair settings in the AppSettings element (MSDN Link).
Once you have your basic settings defined, you can then right click on the config file and click Add Transformation. This will add transformations for each of the Project Configurations you have. (by default Debug and Release).
It will look like this:
Now you can build deployment packages.
Or install Slowchetah and then when you press F5 to debug it will run the selected project configuration with the configuration transformation applied.
We recently switched to team foundation server 2010 for our source code management, everything works just fine, except for some legacy code written in FoxPRO 7 and 9, source code files are some sort of tables. For Forms, there are two kind of files, one ending in .scx and another in .sct, both can be explored using the fox studio but there is no way to open them in a text editor.
does anyone have any experience getting the fox code to work/merge... on TFS ?
I'm not aware of all of the ins and outs for source control and FoxPro, but if some of the source is binary, you can configure file extensions to disallow merges.
Right-click on the collection (root node) in the TeamExplorer window. Go to Team Project Collection Settings | File Types.
You should be able to add the extensions (like .sct), and specify that merging and multiple checkout is not allowed for those files.
The downside will be that only 1 person at a time can check those files out, but since the forms are FoxPro tables, I would imagine that's the same problem that you would have with any source control tool.
For merging you can set up a merge tool that is capable of merging those files. This must be done on every developer station (Tools->Source Control->VS Team Foundation Server->Configure User Tools).
It may be that VS uses a server-side merge tool to do auto-merges, I don't know if or where you can change that.
I've worked with VFP since it was FoxBase back in late 80's. Visual Foxpro used .dbf files (renamed extensions) for purposes of building forms (.scx/.sct) and visual class libraries (.vcx/.vct) and reports (.frx/.frt).
I've written some code to run through a given project and dump out a text version of all the code as if it was all text-based. All the controls are dumped in alpha order, embedded procedures, etc too. List all property settings in same place too.
Its not PERFECT, but I've used over the years in comparing source code versions when dealing with other developers who liked to change things and not notify me (or others) of such changes and finding later by other horrendous means.
If this is something you might be interested in, I can strip-down the code (some) and send it to you via an email, but would need an email address. The code is written in VFP as a .prg file, so nothing compiled that you would need to worry about any viruses or anything.
At least this way, you COULD get a text version associated with the binary pair's of files used within VFP.
I'm currently implementing a vsix extension tool window which will soon need a database connection string for querying some data to display to the developer in the tool window. I'd like to make this connection string configurable by the developer. As the developer is unlikely to change the config settings often a file would be sufficient.
Is it possible to just use an app.config file in the same folder as the sln file and if so must I use some custom configuration settings to wrap the file? NuGet seems to implement this approach but I don't fully understand the internal architecture to see how the config file is used.
I'd appreciate any alternative approaches too.
Edit:
I have since realised that the dynamic data the config store would serve must be solution specific so that a tool window used in one solution can use different properties to that of another solution. I guess one possibility would be to use the .settings file to store the location of a single config file that itself stores information related to different solutions.
The best place to store settings for a .vsix extension is to use a .settings file. In order to create one do the following
Right Click on the project and select "Properties"
Go to the Settings Tab
Click on the link to create a default settings file
This will create a couple of files in your solution.
Settings.settings
Settings.Designer.cs
Additionally it will bring up a designer from which new settings can be added. These can be accessed afterwards by using the Settings.Default static property
Been there and in my opinion the built-in mechanism works best, detailed walkthrough: http://msdn.microsoft.com/en-us/library/ff460144.aspx
Adding a note from self I can see that the underlying implementation uses system registry subkey. However after VSIX extension uninstalled all the keys are removed automatically so your extension is not polluting the system leaving orphaned entries.
I am moving now from VS 2005 to VS 2010 with products consisting of few solutions with numerous projects each. I wanted to make use of the property sheets system so our numerous configurations would be easier to maintain.
One of the issues is that we want to use Windows SDK 7.1 (as we need BaseClasses sample - and if we have to use that sample that why not the entire SDK)? But this requires me to change PlatformToolset on each and every single project in all the solutions. Also we will have to remember to change that value for newly added projects. Rather bad idea.
So I wanted to set this (among other things) from a custom property sheet. There is no such option directly from dialog shown when setting properties on property sheet. Adding entries manually to the XML file didn't help as well (but I haven't also seen any error or warning message).
Then how am I supposed to set default PlatformToolset value? At best in a configuration file which can be committed to repository. But if it could be done in some computer local settings then it would be acceptable too.
(Note that I know that I can use BaseClasses differently and avoid that problem at all but I think it is interesting issue in itself.)
I also asked this question at MSDN Formus.
PlatformToolset must be set in project properties at the begin of the file before inclusion of other files so that it can be later used to set up some defaults. If non is set then those inclusions will set it up to some default value.
Resetting it later even if works is pointless as everything was already included/set up. So to change the default value to a different SDK it seems VS configuration files (those which are included) should be changed appropriately.
But this does not have to be a good thing because it is local for the machine.
There is also an option of manual inclusion of property file which sets the PlatformToolset before default inclusions. However MS warns that if project file does not keep proper order (and this would spoil the order) VS GUI tools for project set up might not work properly.
In the end I just manually changed all projects. New projects also have to be changed to the new PlatformToolset.