In CRM 2013 when deploying new customization's do plugins and workflows that have not changed need to be re deployed?
No, you do not. Solution imports are additive. If you are moving your customizations via unmanaged solutions from a development to a production environment you do not need to include the plugins or processes if they are already in your production environment and have not been changed in the development environment.
For more information on solutions check out this link: http://msdn.microsoft.com/en-us/library/gg334576.aspx
Related
Currently we are using TFS 2017 update 1 on premises but we have to Migrate TFS at VSTS cloud platform. Also we TFS Build Servers on premises having XAML builds using customized build template. Our problem is after migration all XAML build definition would working as usual or not?
Currently we are using TFS 2017 update 1 on premises but we have to Migrate TFS at VSTS cloud platform. Also we TFS Build Servers on premises having XAML builds using customized build template. Our problem is after migration all XAML build definition would working as usual or not?
there is no code. Do we need to Re-configure all build server again?
After migration on VSTS can we configure All build servers on premises as well using old all XAML build definitions or not?
Please suggest on this.
XAML builds are still supported with Azure DevOps Service (with some limitations), see official response from Microsoft:
XAML build is still here until now. Current state :
If you have any XAML build data in your team project collection, you
will get a warning about the deprecation of XAML build features. You
will need to use VS or Team Explorer 2017 to edit XAML build
definitions or to queue new XAML builds. If you need to create new
XAML build agents, you will need to install them using the TFS 2015
build agent installer. Please refer to official document -XAML builds:
https://learn.microsoft.com/en-us/visualstudio/releasenotes/tfs2018-update2#xaml-builds
And we will keep it longer, how long does it can be used depend on
user feedbacks.
Installing TFS2015 Update 4.1 locally allows you to configure Build Server, Service and Agents that are connected to Azure DevOps Service, and run all your XAML builds from either Azure DevOps or Visual Studio.
XAML builds are no longer available in VSTS, so they will not work at all after a migration.
The good news is that TFS 2017 supports build vNext so you can convert your builds before you migrate to make sure you can still build after the migration.
Build vNext (Azure DevOps Pipelines) are much more flexible and easier to set up and customise than the old XAML builds. However if you have a lot of customised builds then it might take a while to convert them all.
One big advantage of the new build system is that the same build can be used across multiple branches, which might mean that you don't need to put as much effort in to converting builds as in the XAML system you needed a build per branch.
My suggestion is that you begin by familiarise yourself with the new build system and start to convert the builds before you migrate, then you can import you TFS database in to VSTS.
Using Visual Studio 2017 (RC), I am trying to setup a project that uses ASP.NET Core, but with the .NET 4.6.2 library.
This is a supported configuration:
Visual Studio will then create a default project; but it doesn't run:
This is without changing a single line in the project: the VC2017 template just does not work.
I tried the following:
- Different versions of the .NET framework
- x86, x64, AnyCPU
- Clear the NuGet cache
- 'Repair' options on Visual Studio's installer.
My understanding is that the error is a x86/x64 mismatch. But since I didn't change a single file from the template, there has to be something else wrong.
Installing ASP.NET Core on .NET Core works perfectly, so the problem is limited to using the regular .NET framework.
Any ideas?
I have the same problem too. But I just found the solution.
In ".csproj" I change some things:
<PropertyGroup>
<TargetFramework>net462</TargetFramework>
<!--<RuntimeIdentifier>win7-x86</RuntimeIdentifier>-->
<RuntimeIdentifier>win10-x64</RuntimeIdentifier></PropertyGroup>
And I enable the 64-bit version of IIS Express.
I had problems like these when I restored stuff to a new laptop.
I mindlessly I copied files from my old profile directory to a directory with the same name, but that isn’t a profile directory on the new machine.
A part of this process involved a cloud backup service that my wife bought for me but that I never actually set up right. That also copied files to new locations without my paying attention to what was happening.
I still don’t know (yet) exactly how the machine keeps track of which versions of frameworks and tools to use in the various application directories, but I can report what I did that finally allowed me to create new .NET Core apps on the new machine.
I deleted everything in this directory that was older than today.
%USERPROFILE%.nuget\packages
Again, pretty mindless. I don’t know, (yet) if all that was necessary. Maybe just deleting one or two of the files/directories would have worked. Regardless, I was very happy to see that I could create and develop .NET Core apps on my new machine.
Im having a hard time figuring out what the best approach is when designing my build process. It seems Microsoft have turned things around (again).
I am using TFS 2015 and Visual Studio 2015. For earlier versions of TFS I have normally created custom code activities that I plug in to my build definition process file (xaml). I like this approach because it gives me great flexibility and enables me to code .NET classes. I used these guides:
https://msdn.microsoft.com/en-us/library/dd647551(v=vs.120).aspx
http://www.ewaldhofman.nl/post/2010/04/29/Customize-Team-Build-2010-e28093-Part-4-Create-your-own-activity.aspx
In TFS 2015 it seems that there is no documentation on how to create custom code activities. In fact, it seems that Microsoft have changed things and now focuses on scripting languages in stead of custom .NET code: https://msdn.microsoft.com/en-us/Library/vs/alm/Build/steps/index.
I have created a custom code activity and it seems to be working in TFS 2015 (with a few hacks) so it is still possible, but I am nervous that this approach is no longer the way to go.
Can anyone provide information about what is happening here?
TFS 2015 introduces new builds, which are web- and script-based, and highly customizable. Meanwhile, TFS 2015 will continue to support the XAML Build templates and controllers.
The new builds are based on a different architecture and run on a completely different system. Currently, you can use both the new builds and agents alongside your XAML builds, controllers, and agents.
Which builds should I use?
If you are new to Team Foundation Server (TFS) and Visual Studio Team Services, you should use this new system. Most customers with experience using TFS and XAML builds will also get better outcomes by using the new system.
The new builds are web- and script-based, and highly customizable. They leave behind many of the problems and limitations of the XAML builds. For example, this new system embraces the diverse set of domain-specific languages (DSLs) that developers used to build the code on their dev machines. We expect this will reduce the chances of running into the "builds fine on my machine but not on the CI server" problem.
If you have heavily customized XAML builds and custom activities, you can continue using those builds until you are ready to port your business logic into scripts that can run in the new builds.
Useful articles for your reference:
https://blogs.msdn.microsoft.com/visualstudioalm/2015/02/12/build-futures/
https://msdn.microsoft.com/en-us/library/vs/alm/build/feature-overview
Our main website is a collection of 10 separate ASP.NET projects and applications. At the moment, to do a complete deployment onto a fresh server involves running ten separate msdeploy jobs; each application is built, configured (using config transforms) and packaged, but we don't have any solution for deploying all the packages as a single operation.
I can see several possibilities that might work in this scenario, but would love to hear from anybody who has succeeded - or failed - in setting up something similar:
A folder full of packages and deploy.cmd scripts, with a "master script" that will call each individual app script in turn and deploy that app to the target server.
Using a staging server where we deploy the latest build of each package from TeamCity using the production configuration, but then use msdeploy to capture that server into a single enormous msdeploy ZIP package, which is then deployed onto each production server as a single msdeploy step.
Creating a single, enormous Visual Studio solution that references EVERY project in our codebase (perhaps via svn:externals?), compiles and cross-references them ALL, and hence supports using a single msbuild job to create a huge monolithic package containing our entire codebase, built from the latest revision in source control and configured for the target environment.
I've studied Troy Hunt's excellent "You're Deploying it Wrong" series, and Scott Hanselman's "Web Deployment Made Awesome" article, but I think I'm looking for something a step beyond either of these approaches that incorporates multiple projects and applications without necessarily building them from source in a single step - any ideas?
We had a very similar scenario in our company, and we created an installation package using WIX. Our config transform happens at installation time, so now we create a single build, then deploy that to each server via an MSI install package. WIX is very flexible, but also has a steep learning curve. We modify our configs using our own custom action, but it could be done other ways.
We use Team Foundation Server and MSBuild to do our builds. This is pretty straight forward, but did take some work to set up correctly with as many projects and solutions as we had.
Other options we looked into, and even tried were:
InstallShield - Not flexible enough.
Writing our own C# Install - WIX already thought of everything we
were trying to accomplish so why reinvent the wheel?
Just saying to heck with it all and installing things manually - 2 or
3 months of development time in WIX and MSBuild have easily paid for
the hours we would have spent of the last year doing things manually.
I think the deployment tools built into Visual Studio were designed for a single application with just a few deployments. It sounds like you need external tools, and development effort, to get your deployments quicker, and eliminate the need for doing things manually. That's why we invested in the above solution, and it has really paid off.
I'll pick Installshield.
Installshield latest versions support creating webdeploy packages.
You can define the IIS configurations for all apps in a single project and create releases if you want to create packages by separate or one single release for all web apps.
Installshield project has an object model where you can automate basically every task from build scripts, also the projects are simple xml files that you can also modify in automation scripts if required
Developers can modify update WixXML projects by separate and you can add those projects builds as merge modules to your installshield projects through your build scripts with some little tweaks to the installshield project xml (at least in 2011 version, this part is not supported by installshield but can be done)
You don't even need to modify Visual Studio Projects for groups of web apps that follow a same pattern, neither manually modify your installshield project to add new web apps for these cases, you can create packages for new web apps without intervention setting one time your build scripts for the installshield project automation task based on the root VS build output
I want to automatically activate a feature (specifically the SharePoint Server Publishing feature) automatically when I deploy a new wsp solution. Is this possible.
Where and How do I do this inside the visual studio Sharepoint project?
Hi Luis Please check this solution how to activate feature programmatically
http://social.technet.microsoft.com/Forums/en-US/sharepoint2010programming/thread/9812889d-954a-43ef-9377-6561e91f3bbf/
Look at the properties on the feature within VS -- there are a couple of options there that will control how the features behave when the solution is deployed via VS ( only ).. these settings have no affect on the solution once it is out of VS...
Activate On Default - Indicates whether the feature is activated
during installation
Always force Install - Indicates whether the feature is installed by
force, even though it is already installed.
Auto Activate in Central Admin - Indicates that the feature is
activated for administrators in CA...