Attempting to migrate a web part solution from farm solution to sandbox solution. The steps I have seen online outline changing a property at the project level which is a boolean called 'Sandbox Solution'. However I do not see this option when I view the properties of the project. Does anyone have and ideas on how to migrate a solution which contains multiple web parts from a farm solution to sandbox?
I am afraid this can't be done. When a farm solution is created and deployed it loads extra controls into the solution that allows the solution to easily access data outside of its container. An example is the user control. This control is not allowed in a Sandbox solution as it allows access to the SharePoint root. Just changing that option isn't going to revert that option because the entire solution is geared around it even if you don't use it. It will be deployed. I found the blog post you are talking about or one similar to it and have never seen that work. This is why you define your project type at the beginning because Visual Studio applies the different controls depending on your selection. Removing the sandbox and recompiling will not work.
On another note, you can however convert a sandbox solution to a farm solution. This is because you are moving from stronger security to "less"
Related
I have a few (3) core projects I want to share across many solutions (12+).
So, say I have 12 websites and they use some shared back end core code (in this case I'm not talking about shared js, css or views - I'm talking about business objects, entity stuff, etc.).
I need to be able to identify which site has which version of the shared code in dev, test, prod, etc. so a developer can get the website code and get the right version of the shared code to develop or patch the website.
And then the MS build server needs to know which version of the shared code to get for the deployment.
To solve this, I'm seeing people branch that core code - which seems absurd to do 12+ times. (I do expect to branch the core code sometimes for things like hot fixes and long running projects.)
I'm also seeing people copy DLLs of the core code and check those in.
I would think I would list the dependencies for my solutions based on TFS label names somewhere so developers can easily get the apps running with the right code and given a tfs label the build server can get the code for the website and the proper version of the core code. I'm using TFS & VS 2013 at the moment too, so there's that.
So, is there a way to do this that's straightforward, supportable/scale-able and intuitive? Thanks - Peter
Labels in TFS is very limited. For example once the label created you couldn't change and update it. If one of your core projects updated, did you need to create a new label for it. If you did and use the new label for one of your solution. However you found there are some bugs in this update, you need a newer update of your core project to fix the bug. Then a newer label created, you need to manually maintain the dependencies which seems not to be an easy job.
Moreover how to list the dependencies for your solutions based on TFS label names? TFS don't have this built-in option, seems the only way is store it in a txt or someother files and check in the source control. Every time the developer open a website application need to check it first and get label from server to their workspace and work on it.
Usually the purpose of sharing code between projects is reducing maintenance. There’s two main code sharing paths: source and binary. The difference between them you could take a look at this blog: Code Sharing in Team Foundation Server
Sharing code between products is a primary cause of quality erosion and elevated bug counts. I would recommend you to build separately and sharing binary output through NuGet which use preferable.
Also take a look below similar questions:
Sharing code between solutions in TFS
TFS 2010 Branch Across Team Projects - Best Practices
I am using VS.net and TFS. In the past I have stored my technical documentation (explanatory documents etc) in TFS document WSS repository and linked it to my source code via the Story, Task or other work item. This has proved unsatisfactory in the long term because the documentation is not strongly linked to the code it describes.
What options do I have to link documentation to code in VS.net/TFS other than through the work item. I can think of two options immediately -
1) Add it as Content to the project or solution itself and store it in the source code control repository
2) Add it as a URL in the code header, and store it in the TFS WSS document store.
Both these seem unsatisfactory - (1) means the documentation is not available outside the SCCS, and (2) means the programmer has to hunt through code to find the documentation link (which could be anywhere in any header).
Are there any other options that are in common use ?
Phillip
I don't know if there is a single golden answer to your question. But let me share how I do it.
Personally I split my documentation in technical and business documentation.
Technical documentation only consists of four documents:
What are we building, short document that you can give to a new developer to get quickly up to speed what the project is all about.
Instructions to compile. This document describes any steps a developer needs to take on a completely new machine to compile the code and run unit tests
Instructions to deploy. All necessary information to deploy the app to a new environment
Technologies. A list of technologies used in the project with links to more information if a developer needs to learn something.
This documentation is stored in a solution folder as part of the solution in Visual Studio.
Outside stakeholders can view this documentation through the web access of TFS. They can't change it however without having Visual Studio or Team Explorer and knowing how to use those.
For all other documentation we use SharePoint. TFS allows you to link Workitems to documents in SharePoint. We try to avoid any technical documentation in here.
Another option that you might consider is to create a new Work Item type called "document" and to have a hyperlink from here to the document location. Now you can create hard links between code files and changesets as well as PBI's to originating documentation.
In addition, when documents move you only have one place to update it.
I have a multi-tiered ASP.Net MVC 3 application in which different layers need to share some settings, and I am wondering how to best achieve this.
For now, all my AppSettings are in the Web.config file, but I just added a new project to my solution to create a console application that will be called every night buy the Windows Task Scheduler to perform routine maintenance tasks. This console application will be using the same database, repository layer, service layer, etc. as the web application, and both applications should share the same settings for the most part. I would like to avoid duplicating the settings in two files (app.config and web.config).
Also, I want these settings to be available to the service layer, which is in a separate project in the same solution.
I have read the following post, but I don't fully understand the solution, and I am not sure it is the best way to do this.
Sharing Config settings between Web App and Console App
I also read the article linked to by that post, and I don't find the solution very elegant.
I am using VS 2010 and EF 4.3.1.
If you're simply interested in accessing the AppSettings of your web.config file from a console app, that's simple enough. The only real annoyance is that since your console app won't be running in a web context, you will have to know in advance what your site is called in IIS. This being your own application shouldn't be a challenge.
Just use System.Web.Configuration.WebConfigurationManager to open and access the web.config of the specified site.
The idea is that you could put the settings into a common .config shared between all your projects as a link instead of putting it in all projects. The solution is outlined in this answer. Also checkout the configSource property on MSDN if you are not aware about the possibility of externalizing configuration elements into a separate file.
We have some legacy Classic ASP websites to maintain, and are wanting to use VS2010 to edit them, due to familiarity because of lots of .Net work.
I can open the website inside Visual Studio.
I can configure IIS to run the website based on the working folder used in VS2010.
I can configure VS2010 to automatically open my default browser pointing to the correct location, using the 'Base Url' setting in the Properties page.
What I CAN'T do, is work out where VS2010 stores this value, as there's no mention of it in the solution file that VS2010 has created, and as there's no project file for the website, there's nothing there too. Yet, when I close and re-open VS2010, it somehow retains this information.
This is important to me, as I need to be able to commit all files to our source control for use by other developers and, ideally, not have them worry about setting this value themselves.
So, the question is: Where does Visual Studio 2010 store the Base Url when working on Classic ASP websites?
I don't know where this is saved, but in tracking things like this down in the past I typically take the following approach:
Open Visual Studio and change this one setting
Apply the changes
Look for all files that have been modified in the last 1 minute in the project folders and in the Visual Studio folders
You can be sure there will be at least a few other files changed that are not relate to this, but it should narrow your search. You may want to re-close VS before searching too, but that will modify other files as well (making for a slightly larger pile of changed files to sift through).
If you still don't have it, search the registry (but I cannot imagine this would be where it was storing anything project specific).
EDIT:
Just created a new project and played with setting this property. It is definitely stored in the .suo (Solution User Options) file for the project, in the root of the project folder as #Lankymart suggested (and is a hidden file if you are not seeing it). It is not stored in plain-text.
You may be able to access it programmatically here: http://msdn.microsoft.com/en-us/library/microsoft.visualstudio.shell.interop.ivspersistsolutionopts.loaduseroptions.aspx
As there are a ton of absolute path settings in these files, moving it to other environments is not really an option. I would suggest you are stuck with project start up documentation that lists these settings as part of the project setup process. I think any other solution is going to be equally annoying|fragile (or worse).
Not sure if there is another way to accomplish what setting the base URL does without managing from the Start Options panel - that is likely your last-best hope for a solution.
I'm working on a website at the moment that has three separate "area's" to it. Firstly, there's the main website, then there is a User control panel, and finally an Admin Control Panel.
At the moment, I am working with three separate solutions which is less than ideal, as I can imagine updating this in the future will become rather messy.
What I would like to do ideally, is create a solution, and then include the three separate projects within that solution. I don't have a problem doing that, what I can't seem to figure out however is the publishing side of things.
I've searched around and been unable to find a solid answer to my question, which is:
If I am using multiple projects in one solution, can each one be published to a separate FTP Server Directory? -- I would also welcome any ideas on how this could be done better.
My apologies if this question has been asked before, but during my searching I have been unable to find anything that relates to this situation.
Thanks in advance,
Dave
This is definitely possible, since publishing occurs at a project level rather than at a solution level. What I like to do is go to Tools->Customize->Keyboard... and set a custom key binding for "Build.PublishSelection". Whichever project you have highlighted in your Solution Explorer will be published when you push the key binding. You can save multiple publish configurations in the publish dialog as well.