How to extend Visual Studio with TFS to override the Get command - c#

I am working on a conversion from Accurev to TFS and am being blocked by Accurev's usage of symbolic links, which TFS does not work with. I have tried several methods, but they all seem to fail to work.
What I would like to do is have a file in the project/branch that lists all the linked files and folders that is stored in source control. On every get operation, I would like to read this file and link the folders and files specified in the central file. However, I cannot find a way to extend the get operation. Does anyone have any experience in extending it in VS?

TFS does not provide a way to extend what happens on a Get action. You could easily create a custom powershell or batch file that you use in place of calling tf.exe, but since Team Build and Visual Studio call into TFS directly using the Client Object Model you're not going to make this easy on yourself.
In the end everything is possible of course. You could write a custom build action for Team Build to replace the standard get operation, or create one that triggers after the standard get operation has completed. You can write a vsix visual studio extension that replaces the standard Get operation everywhere in the menu's of Visual Studio and get to a something that could be considered workable. But I would not recommend this. It is far from standard and it is far from sustainable. You'll have to unwire so much default behavior in Visual Studio (that checks out files that are changed, adds files to source control when they're added to the project file etc etc etc).
SourceSafe used to have this feature as well (it was called pinning) and Microsoft removed it when they created TFVC. They now recommend you use branching and merging to synchronize these files across multiple projects, making sure that the source structure in Source control is the same as the ones on disk during build.
You can also make use of the Add-as-Link option in your project files. This allows you to keep the original files in their original location, but MsBuild will understand that in the project structure this file actually lives somewhere else. Or package the linked files up in a NuGet package and use the Dependency Management using NuGet guide to help you place the files in the right location during build.
And finally, you can get very creative using Workspace Mappings, many people never get further than mapping $/project -> $(SourceDir), but in essence the workspace mapping is like the file you describe. A way to layout your sources from Source control to disk. You could do:
$/Project/DEV/MyProject -> $(SourceDir)\MyProject
$/Project/Shared/FilesToCopy -> $(SourceDir)\Shared
And you can even add files from other projects in the same collection:
$/AnotherProject/Shared -> $(SourceDir)\MoreShared
And something not many people know, you can layout individual files:
$/AnotherProject/CompanyAssemblyInfoItems.cs -> $(SourceDir)\CompanyAssemblyInfoItems.cs
The only thing you cannot do, is map files to be children of an already mapped folder. In that case you might need to have the workspace mapping do the fetching of the sources and then a .targets file that you include in your .csproj file to do the copying of files.

Related

How to build different editions of an ASP.Net Webform by excluding some folders and files?

I hope it's not a duplicated question since I searched enough about it but I found nothing, maybe that's because I didn't know the appropriate words describing my situation.
The question:
Summary: Can Visual Studio build different editions of an ASP.Net Webform just by a simple wizard or something like that? Some Cs, Js Or Css files or some folders shouldn't be involved in the final output.
Detailed:
We have had a very large ASP.Net project containing lots of folders and involving lots of features, we have been offering the whole project to customers and we have been protecting it by License approach (which applies Private and Public keys mechanism).
Now the company considers to offer different editions of the application based on the customer type, so if the customer is a small business it will be offered an application with less features since he is going to pay less money.
Keep in mind that we don't want to offer customers the complete application and then based on the permission which are defined in a table in the database he can get access to just the features we tend, It's no that good, beacuse after he are given the limited edition license, he is able to change his permission by modifying the related table in databadse or if he dissemble the related Cs or dll files (I have read about obfuscation to make it safer)
They wouldn't gain anything even if they grant required permissions complately to themselves beacuse they don't have required files.
I had hared of an application which is used to manage -or better to say customize- the project build process, what is the best solution? would you enlighten me?
I would highly recomend you to look into build configurations in visual studio. There you can choose what project files to build and control the output.
Check out the following for more details:
https://msdn.microsoft.com/en-us/library/kkz9kefa.aspx
I'm still looking for the best solution but for now, after searching a lot I found some solutions applying MsBuild, for instance to exclude some folders and some files from being published you can add following script in visual studio project file (.csproj):
<ItemGroup>
<ExcludeFromPackageFolders Include="Scripts\large">
<FromTarget>Project</FromTarget>
</ExcludeFromPackageFolders>
<ExcludeFromPackageFiles Include="Scripts\mash.js.chirp.config"/>
<ExcludeFromPackageFiles Include="Content\mash.js.chirp.config"/>
</ItemGroup>
This will cause the following folder and files to be excluded:
Scripts\large
mash.js.chirp.config
You should add above script in .csproj xml config file exactly below the line which says:
<Import Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v10.0\WebApplications\Microsoft.WebApplication.targets" />
Here's some useful links: This one and This one
Keep in mind that there is no visual studio project file in Web site so you can apply it in Web application but Website, Here is the source from MSDN.
Although here it's told that you can use MSBuild even if it's about Website, Take a look at this link so you'll learn how to create a project file for that purpose.

How to copy additional files on build?

I have a WebApi2 application and it references other projects within the solution. One of these includes some files that I want copied on build. These files have their Copy to Output Directory property set to true.
The files are correctly located in the bin folder of their assembly.
However:
After the build I need them to be copied to the App_Data folder of the web application
Included in the files that get published to IIS
Is it possible?
From my experience you are going to have to get your hands dirty with MSBuild. Its been ages since I've used it but you will need to use the Move Task
This is what Visual Studio uses in the background to build the projects. It may seem daunting but is actually pretty simple once you get used to it. There are tons of tutorials online.
Alternatively, and the most straightforward way, is that you include the files in the APP_DATA folder from within the solution.
EDIT: As mentioned by robor78 you will need to call the Move Task in the Post-Build event
Add build events
In Visual Studio -> Solution Explorer -> right click the project -> properties -> go to build events.
Use something like xcopy
Also if click on "Edit Post-Build" you will see a list of useful folders and file names which you can use e.g. $(OutDir)
You can use Xcopy from the Post build event. It is pretty straight forward but will not run if code not changed. So if you update configs etc. you must force the build I beleive.
See here for how to use xcopy.
http://commandwindows.com/xcopy.htm
There are wild cards and all kinds of useful features, but your situation is pretty simple. Just copy from $(ProjectDir)/bin or something like that to a path.

VS2010 - Adding new projects do not inherit existing build configurations

I have a Visual Studio 2010 solution with many projects and many build configurations in order to make use of Web.config transformations for automatic deployments.
My problem is when a new project is added it does not inherit the existing configurations and thus the build fails on the build server.
As an example, say I have the following custom build configurations:
Development
QA
Production
When a new project is added, it only contains the standard Debug and Release configurations and none of the above custom configs.
The only way I know how to fix it is to manually edit the .csproj file.
What is the proper way to handle this?
Edit I have removed the information about why it fails on the build server because that is irrelevant (and obvious), I just need to know if there is a way to have existing custom build configurations automatically picked up by a new project being added to the solution.
The proper way to handle something you have to do manually on a computer is, usually, doing it automatically. No kidding. All our project files (both C# and C++) are generated: they automatically import the correct property sheets with all build options and all have the same platforms/configurations. It's a relative small amount of work to throw together a program that will save you much more time and effort later on. Basically the Microsoft.Build.Construction namespace has everything you need. To make the program user-friendly we added a small ui on top that lets you drag in directories in which to create projects. So we just run it, create a directory, drag it onto it and add the new project to the solution in VS.

What is the best way to publish multiple versions of the same ClickOnce application?

I have a c# ClickOnce application that I need to be able to publish multiple times for OEM purposes.
The way I understand it now is that publish settings are located in the .csproj file.
However, this is inconvenient in the case where I want to publish multiple versions.
for example, Company A needs totally different icons, start menu location, product name etc. from Company B, but the assemblies need not be renamed.
Here are a couple approaches/questions that I can think of to solve this issue...
1.Is there a way to create a separate publish settings file to use during build time?
2.Can I edit specific publish settings (like Start Menu location, etc) at build time with MSBuild.exe? I think this would be ideal...
e.g.
MSBuild.exe project.sln /target:Publish /property:edit-project-publish-settings-here
3.Maybe create a 2nd .csproj file? (Would prefer not to do this...)
Please share your thoughts as to the best approach, or any other clever ways to make this happen. Thanks!
I wish I could give you some brilliant solution, but personally I would probably go with option 3.
I mean, its pretty simple, the changes should be pretty static and it will be difficult(ish) to totally screw it up and deploy the wrong changes to the wrong company.
If you copy the .csproj in your project folder, it will reference all of the same source files and you can just change the executable name. Create another VS solution and you can reference the copied .csproj and get rid of your first one so that you can publish two separate versions.
This isn't ideal for ClickOnce however.
If you use a Singleton object that specifies the "mode" (Company A, B, C, etc.) you can easily store that in the app.config (or another xml file). Then just re-publish your ClickOnce Application but copy the correct version of your configuration file in so it gets shipped with the build. This way, you don't need any additional csprojects Just include all of your icons and set them at run-time on App Start based on your Singleton object.
I found that you are able to edit certain properties using MSBuild.exe like this
MSBuild Solution.sln /target:publish /property:ProductName=ProductA\;Publisher=CompanyA\;ApplicationIcon=companyA.ico
I found another useful post on modifying.csproj files programatically with .NET code. (This would only be needed if you're modifying things that are deeper than just the project properties specified in the ClickOnce documentation below)
The MSBuild documentation here was also useful -- especially under Publishing Properties

How can I share common style information (css, images, etc.) across MVC sites?

It's dead simple to share functionality across multiple MVC projects. You just put the code into its own project and reference it in as many solutions as your heart desires. Clean, standard, glorious.
Is there any means to do this for styling code? I'd like to have our common CSS files, the ones that give our applications a similar look and feel, in just one place. Right now I have to spawn new copies for every new application. Thus if something needs to be fixed, it needs to be fixed a dozen times in a dozen places.
Has anyone else dealt with this? I can't separate out the CSS files into their own project, nor do I really want to have a web application that's just css sitting somewhere so all of the applications can use the files remotely via fully-qualified Urls. Is there a TFS trick you can do with source control to link the files together? Is there something I haven't thought of?
Here is the "dead simple" solution for sharing web resources between projects without using CDN, LESS, SASS, NuGet, etc:
Create common Solution Folders containing the resources to be shared, or simply designate one of the projects to be the master.
Use "Add as Link" to add the shared resource files to each project as needed.
Add an AfterBuild task to each project file that will copy the linked files to project folders. This is only needed so that Visual Studio test/debug (F5) will work locally.
If you need the details on how to do this, keep reading.
Configuring Solution Folders for the Shared Resources
** Note that if you're simply going to share files directly from one project to one or more additional projects then you can skip this step.
Visual Studio solution folders do not have to reflect physical file system folders, but doing so will help preserve your sanity. So first create the folders on your local file system and copy the resource files into them. The new folders should be located under your solution folder. For example:
\MySolution
\Common
\Images
\Scripts
\Styles
Back in Visual Studio, right click on the Solution Items folder and use Add Solution Folder to replicate the new file system folders.
Next, add the files to the new solution folders by right-clicking each folder and using Add Existing Item to add the contents of the folders.
Add Shared Resources as Links
For each project that will use the shared resources, right-click the project folder and choose Add Existing Item. Browse to the common folder, select the desired files, click the drop-down arrow next to the "Add" button and choose "Add as Link".
You may get a source control warning about adding files that are outside of the project directory structure, but this can be ignored since the linked file will be under source control at its source.
Add an AfterBuild Task to Copy Files
When you publish the application to a server the linked files will copied to the project folders to which they are linked and everything works as expected. However, in the development environment the linked files do not physically reside in the project folders. So when you hit F5 to test your application in VS, the shared resources will be missing.
The simple solution is to add an MSBuild task to copy the linked files from their source after each build. This needs to be done to for each project that contains the shared resource links.
Right-click the project and choose Unload Project. Right-click the project again and choose Edit <ProjectFileName>. Scroll to the bottom and add the following (just above "</Project>"):
<Target Name="AfterBuild">
<!-- Copy linked content files to local folders so that they are available in the debugger.
This is only an issue when running the application locally. The linked files should
be automatically published to the correct folder when publishing to a web server. -->
<Copy SourceFiles="%(Content.Identity)"
DestinationFiles="%(Content.Link)"
SkipUnchangedFiles='true'
OverwriteReadOnlyFiles='true'
Condition="'%(Content.Link)' != ''" />
</Target>
** Copy task adapted from this link in TheCodeDestroyer's answer.
Save the project file then right-click and choose Reload Project.
Why not just have one site host that base styling and the other sites reference those styles? I don't see anything wrong with this.
You could create a CDN application of sorts to do this, too.
MVC App #1
<link src="~/css/styles.css" />
MVC App #2
<link src="http://mvcapp1.com/css/styles.css" />
Well, I don't know much about asp.net development, so forgive me, if it's not the case, but
If resource files in your project have Build Action set to None or Content and Copy to Output Directory set to Copy..., you can easily create the Class Library type of project and place all the files there (preserving the paths), and then reference this "Class Library" in every project that needs the files. Every file will be copied to every referencing project on solution build.
For Embedded Resource build action it will also work, but, you'll need to find a way to specify the assembly, which contains these files (because it will differ from Assembly.GetEntryAssembly).
Personally I don't like or want the CDN solution as if you have many pages they depend on CDNs 100% up time. After some research I found this solution which was perfect for my use I hope whoever will look for an alternative this is one of them:
http://mattperdeck.com/post/Copying-linked-content-files-at-each-build-using-MSBuild.aspx
1 - Look into CSS template systems as mentioned :
SASS-Lang
Less
http://css-tricks.com/sass-vs-less/ (really good article to start, many related items to in his related posts widget)
These allow you to code your stylesheets in organised manners. You can quickly add dynamic configurations and global changes easily.
2 - Developer your own CSS global listing system :
If you prefer not to use the above CSS stylesheet system. Example
//cdn.com/assets/css/reset.css
//cdn.com/assets/css/main.css
//cdn.com/assets/css/page_home.css
//cdn.com/assets/css/page_cart.css
even...
//cdn.com/assets/global/form_styles.css
//cdn.com/assets/global/global_shortcuts.css
In these, the same form padding, table and tr and other padding rules. Example
.black{color:#000 !important}
.right{float:right}
.left{float:left}
I know I sound like framework mentality but it works..
You can quickly alter the global to ensure all pages are updated.
The CDN storage and compass suggestions are valid too. You see storing on a CDN will save the headache of worrying about application failure / speed / load.
Your application can simply be like
/cloud/servers/settings/global/db
/cloud/servers/settings/global/librarys
/cloud/servers/settings/global/css_config.php (example)
/cloud/servers/1/webapp.com/
/cloud/servers/1/webapp.com/model
/cloud/servers/1/webapp.com/view
/cloud/servers/1/webapp.com/view/themes/tpl
/cloud/servers/1/webapp.com/inc
/cloud/servers/1/webapp2.com/
/cloud/servers/1/webapp2.com/model
/cloud/servers/1/webapp2.com/view
/cloud/servers/1/webapp2.com/view/themes/tpl
/cloud/servers/1/webapp2.com/inc
//cdn.com/assets/css
3 - Configuration of Approach
I personally think that the question should be about the approach of your overall development methodology. Having CSS sit on a CDN application, or having a CSS on a separate server which syncs to the CDN for production live mode is a good idea - keeping it separate and maintaining it via a stylesheet language is even better. You can then quickly use skins, css libraries, image libraries and more. Keeps things organised, faster and much better and ENJOYABLE to look at and take pride in coding with.
Keeping it and using a better system is what is needed. You should use manual and the classical approach of a folder structure IMO. You won't have to worry about responsive application design for mobile/tablet and other bearing issues with updating one CSS line for all the apps or even single apps - even languages, and dealing with multi site development teams.
JUST MY HUMBLE OPINION
Would also strongly recommend a CSS stylesheet language, sure many people hate them. But they are becoming quite useful, especially SAAS it's not a hype like NodeJS was.. it actually works. And does wonders. Look at TopShop, GorgeousCouture.. Arcadia sites.. multiple languages, multiple currencies.. servers and teams working on the same cross brand and several applications for each store..
We had the same problem and for our purposes we put all general CSS/JS/Images/Layout View into NuGet package and reuse it from every application where we need it. It perfectly works for us.
If you're open to using Sass, Compass extensions might be just what you need.
http://compass-style.org/help/tutorials/extensions/
An extension, when bundled as a gem, allows you to easily include the styles contained within the gem from anywhere on the system that has the gem installed. I recently used this in my latest application (a specialized multi-user CMS where each user has their own subdomain that has a customized layout, but all of the components/widgets have the same styling throughout the application). Setting up a new subdomain's styling is as simple as running a single command and customizing the template I've setup that has a skeleton of a simple layout.
Compass extensions can be used to hold images and JavaScript files as part of a template, but deployed files aren't automatically updated like the styles are (templates from a Compass extension differ from the stylesheets, as the templates are for copying and the stylesheets are for importing).

Categories

Resources