We've recently upgraded to Visual Studio 2013 and we're having some issues with the new way publishing is handled. Previously, (in VS 2010) every user had their own local publishing settings, but in VS 2013 it's changed to the idea of shared publish settings. This is causing problems with our environment because every developer has a different local dev environment (paths, connection strings, email addresses to send things to). I realize this is not the optimal way to have things set up, but that's the reality of our situation right now.
We use config transforms to handle the various web.config changes for different developers, so just running through VS doesn't work for us because it doesn't run the transforms. This also causes a problem with the VS 2013 publish settings because the last build config used is stored in the shared publish settings. In order to keep all our settings different, it looks like we're going to need to have a different publish setting for each developer now as well (such as "Local - Erik", "Local - OtherDev"). This is just going further down a path I'd like to get out of eventually.
So my question boils down to: Is it possible to somehow disable the shared profile settings? I thought of just not including them in version control, but then Visual Studio complains that the files are missing on other developers' systems.
Thanks for the help!
You can do this by excluding the profile from the project after you create it. The publish wizard looks for any profile on disk, but newly created ones are added to the project by default. If you then exclude the .pubxml file from the project and remove it from source control, it shouldn't bother you again.
Related
We have a C# .NET project using Visual Studio 2013 and we're setting it up to release and deploy with Visual Studio Team Services (VSTS). The websites were pretty simple and easy to set up and they work fine. A few projects are libraries or Console applications and we're trying to determine the best method for creating an automated release for these.
The publish profile asks for a location to publish to - we've experimented with the build drop on our VSTS build server (where all of the other files are) and then asks for a website, a UNC path or a CDROM. We chose "UNC Path" and put the same build drop location in, but in UNC format.
It hasn't really worked yet, so I thought I would see if any best practices for creating VSTS releases and deploys for Console or Code Libraries exist.
Thank you!
Have you considered installing the agent on the target environments and using a release definition that simply copies the right files at the right place?
Regards
Note: copy path shouldn't be hardcoded and rely on variables.
To specify the agent queue by going to the tasks tab when editing the release definition. Click on the "run on agent" header, that will open the details, select your queue here.
Agent queues can contain multiple agents, so your job when you add agents is to organize them by queues that make sense in your context.
Me - Front End web developer with an ok working knowledge of writing VB.NET code but I have never built a .NET project from scratch using Visual Studio.
External developer - Experienced VB.NET developer but completely new to version control and TFS. Also extremely cheap and prone to infuriatingly poor programming practices. He does things that make you bang your head on the table.
Background
Our external developer has coded our site but over the last few years I have been tweaking aspects of pages and have managed to learn quite a bit of VB.NET along the way. He has never used source control and I don't think he's ever had to work with another developer before.
Up until now he has maintained a local copy of the website. He makes changes to this local copy and when he wants us to test it he uploads the relevant files to our dev server. I have no experience of Visual Studio projects/solutions so if I have made tweaks to things I have edited the aspx/asxh/config files in my preferred editor and then uploaded them to the dev server. If everything works correctly I ask him to download them from the server so he can update his local copy.
I have been maintaining a local git repository of the website for the last 2 years. If he makes a change I check it in.
Obviously this is a nightmare to work with so we have now insisted that he starts using version control. I recommended GIT but he has decided to use TFS.
He has now put his solution and all the files into TFS. I have installed Visual Studio 2015 and successfully connected to TFS. I have mapped the files from source control to my own workspace but I am now at a loss as to what to do next.
Questions
As soon as I open the .sln file he has uploaded it says I have checked out the file and made changes. When I check the diff it seems to be because I am using a newer version of Visual Studio than he is. Does the .sln file need to be in version control? Or are we suppose to maintain our own versions of the .sln file and simply check in everything else?
If I try and build the project it fails because the web.config is set up for his machine and not mine. How can we maintain 3 versions of the web.config file? One for my local, one for his, and one for our dev/live environments?
I am not convinced he will have added the project to TFS correctly because he's never used it before. This is basically the blind leading the blind.
Question 1:
You need to put the .sln file in version control. Before check out the .sln file, please do a "get latest" step, which will make sure both of you are working on the latest version. When you try to check your local version in the server, and he had uploaded his local version in the server. You may have to solve conflicts before the check in.
Question 2:
You should build your project and published the website on the server. The build agent will only maintain one version of the web.config file. If he has built the project with his web.config. And you want to build the project again with your web.config, the build agent will delete the previous web.config and pull down your version. Then build the project with your's web.config.
Moreover, if both of you are not similar with TFS. Suggest you taking a look at below MSDN link which related to source control and build.
Use Team Foundation Version Control
TFS Vnext Build
Recently I have intalled VisualSVN and TortoiseSVN extensions in my Visual Studio 2015. I have successfully configured Repository and now it is working fine.
I have also configured svn:needs-lock property to my pages. Now, I need to know who is modifying or using the particular file and which is supposed to be committed.
The problem is that there may be multiple developers might be modifying multiple files and Now, I need a list of files which is exclusively checked out by developers. Just like a Pending Changes Explorer in Visual Studio for whole repository. So, where can I get a list of files which are being used same as Visual Source Safe Control?
If you need any information just ask me in comment I will add it.
Thanks!!
I am trying to set up my WCF service (.svc) to work in Visual Studio 2010 (pressing F5 to debug), but also to have multiple configurations for each environments (DEV, QA, UAT & Prod). When I originally built the WCF it was used purely in Visual Studio 2010 using .Net version 4 and debugging the service was easy enough by adding a WinForm application to pass in the values needed. When it was time to test the service on a server, I used the Publish feature to put the files on the DEV server and noticed that since it was using IIS that a web.config was created in the base directory.
So now that we are moving on to QA and UAT I need to make sure we have the configuration files for each environment as the Uri's change as well as various other values. Now after searching for a few days on Google, I have tried to use the XDT Transformations, but without having a third party add-in like SlowCheetah, this does not seem to work as it is only built for Web Applications. I have also tried to set up a post-build event to copy different configs:
copy "$(ProjectDir)Config\web.$(ConfigurationName).config" "$(ProjectDir)web.config" /Y
The copy process is set in the Build Events --> Post-build event command line textbox, however this does not seem to work when I use the publish method. I am ok with using multiple config files and copying them, I just have not had success with this.
The XDT makes the most sense to me and would be my preference if I could get it working. The main issue I am having is that it needs to work in Visual Studio, but also to work via IIS on the servers without having to go through a bunch of steps per environment. This is a company rule that I have to follow as well as not having a third party plug-in/add-in.
Is it possible to run the service in IIS and create a servicehost via code? I don't think it is as I believe the MSDN docs say that IIS creates it for you no matter what. Part of my reason wanting to do different configs is so that the page the user gets when they view the .svc file in the browser has the correct Uri in it not the machine name version.
TIA
EDIT: Setting up a dev web.config and including it in the project and then setting it to Build Action: Content fixes the copy method, so technically I have it working as long as I have completely different web.config files for each environment and an app.config for debugging (F5 in Visual Studio).
I have a problem which I thought could be common, searched the web for it but found nothing.
We're using a shared development machine, and every developer connects through RDP and has his own profile, desktop, etc.
The problem I am encountering is with IIS express. Since it is configured at user level (applicationhost.config inside documents/iisexpress/config) and the port configured must match the one declared in the .csproj file, two developers can't possibily run on the same port, as it gives the error "the port is already in use".
So to make it work we have to manually change the port both on the csproj and in the applicationhost.config for every developer, but it's only a temporary fix as when we commit our changes to SVN, the csproj file gets merged, so we have to do this process every time someone commits/updates.
My question is: is there a clean way to use IIS express with Visual Studio 2010 on a shared development machine?
Thanks.
Partially tested answer. Not sure how it'll work on a multi-user workstation. It might give you, or someone else here, a jumpstart to a proper solution that works best in your existing environment.
It appears that Visual Studio stores all the web configuration in the csproj/vbproj and IISExpress stores its configuration in %userprofile%\Documents\IISExpress\config\ApplicationHost.Config.
Normally, we store the csproj files in source control, but ignore the csproj.user file so that each person may have some unique settings, such as the web configuration.
Each user who signs into the box must have their own profile.
Each profile must have their own copy of the source code.
Each user's copy of the source will contain their own csproj.user file.
Ignore .**proj.user* files in your source control.
Copy the web settings into the csproj.user by unchecking the option Apply server settings to all users and then commit to source control.
Each user who pulls a copy of the source will have to configure their web settings, use a unique port that the others users are not using, and uncheck the box above so that their configuration is not passed on to the other users.
Doing this, Each profile will have their own IIS Express ApplicationHost.Config configured with a port that is different from the other profiles. Each user's copy of the source will have a csproj.user that is configured with the same port in their profile's IIS Express configuration.
For reference:
I've tried changing IIS Express's ApplicationHost.Config to use a different port than what Visual Studio expects and Visual Studio is unable to connect the debugger to IIS Express.
How IIS Express's configuration works: http://msdn.microsoft.com/en-us/library/ms178109.aspx
The best option you can use is to take advantage of the Import functionality built into MSBuild.
Essentially, you would create a seperate build target for each user. You can then import this target from this referenced file directly. I would then recommend creating this file on the server (for each user), but leaving it outside of source control.
This should allow each user to have a custom IIS port without conflicting with others.
I think you can create subdomains for each user and implement the required changes and do the testing. In this way each user can his own subdomain and port and hence work independently on the shared IIS Express.
You probably won't like my answer but here's my thoughts:
As you noticed, the configurations are tied to the user profile and not the server; this is because IIS Express is not intended to be used as a shared development server. You should be using full IIS.
I do not see any benefit or reason to use the same physical box for development. Admittedly, I don't know all the details of your scenario with licensing or workstation resources, but it doesn't seem like you gain much from having everyone RDP into the box to use Visual Studio - each person still needs a license, performance will be slower, and you shouldn't be working on the same project instance.
You should seriously consider your entire setup for development:
Each developer should use Visual Studio on their workstation, and debug/test there using IIS Express (configured with the same ports and settings across all machines - very easy).
From there, your developers should check their code into source control, and examine conflicts that may or may not arise. I'm not sure about SVN but the MSBuild automation available in TFS can be use to setup a continuous build policy that deploys to a common IIS installation so that your merged code is tested and usable from the full IIS installation mentioned above.
Anything else would be a workaround/hack that will bite you in the butt later.