I want to make an event reciever DLL for both SP2010 and SP2013. currently I have two separate projects one for each as each one is targeting different framework due to the fact that each of them is built using different .NET framework. can I use one project/solution to produce these two different DLLs?
Use conditional compilation in visual studio to switch between dlls of target framework.
Refer below links for help:
http://www.collaboris.com/blogs/collaboris-blog/mark-jones/2013/01/06/multiple-versions-sharepoint-visual-studio#.UrKQkvQW3O4
Conditional Compilation and Framework Targets
Conditionally changing target framework version
visual studio 2010 compiler conditions based on target framework
Because of the fact that a) you have to have the target SharePoint version installed on your dev and build machines, and b) it's impossible to install two SharePoint versions on the same machine, then no, you cannot build two DLLs targeting SharePoint 2010 and 2013 at once. Keep going with two separate solutions, just share the source code and if necessary, use conditional compilation to reflect changes between SP2010's and 2013's APIs.
Related
We have a Windows Desktop only product suite that consists of several .exe applications and (obviously) quite a bunch of shared libraries between these apps. There's about 20 exe apps and maybe also about 20 shared libraries that are each used by several of these apps (some libs are very specific, some are just your good(?) old FooUtils.dll) Most code is C++, some C#.
Currently, all these reside in a single Visual Studio 2005 solution and are all built and released together. That works quite fine and each developer always can edit / see / debug any code he needs to. About 15 devs (mixed C++ / C#) on that product suite.
Now the problem
Due to migration pressure (language features, new 3rd party components) it becomes increasingly urgent to migrate some of the apps (read .exeprojects) to newer visual studio versions. Some to VS 2010 maybe (3rd party dependencies) some to VS2015. And some we just have not the resources to migrate them from VS2005 yet (third party constraints, as well as time/budget constraints).
This means that several of the shared C++ libraries will have to exist for several visual studio versions. (As opposed to the exe projects - these would just be built/maintained for one chosen VS version.)
Now the question
Given a set of (internal) shared libraries that need to be created for multiple different Visual-C++-Versions and that should be easily editable and maintainable for all devs, how are we to keep the Utils.vcproj(2005) the Utils.vcxproj(2010) and the Utils.vcxproj(2015) in sync?
Mostly to avoid manually having to maintain all files contained in the projects, but also regarding project settings / .[vs]props settings for these projects.
Ideas we had so far:
Just accept annoying triple maintenance of 3 project files in 3 different solutions (ugh.)
Use one of the vc.. project files as the master project and automatically (how??!) generate the other vc..files from it.
Use tools like CMake, Premake, ... ?? to generate these shared-shared library projects. (That would mean introducing a foreign configuration tool for our devs)
If you want to avoid manually updating your project files in separate versions of Visual Studio, you'll have to have a master configuration for the project of one sort or another. The two options you listed are basically your options:
Use one project version as the 'master'. In this case, the master must be the oldest version (VS2005 in your case?). Visual Studio has a project upgrade feature, to convert older projects to newer versions. When you load up an older project in a newer version, it prompts you to upgrade. This process can be automated with some simple scripting. Using devenv.exe <project/solution file> /upgrade you can upgrade a project from the command line.
Use CMake/Premake/etc. These add a little bit of overhead, but making supporting new platforms and configurations a lot less painless. If adding new dev tools is cumbersome to your process, and you're only supporting Visual Studio, the first option might be more suitable.
The custom build activity depends on the following TFS assemblies:
Microsoft.TeamFoundation.Build.Client.dll
Microsoft.TeamFoundation.Build.Workflow.dll
Microsoft.TeamFoundation.VersionControl.Client.dll
The goal is to compile it in such a way that it will work on TFS 2010, TFS 2012 and TFS 2013 without having to manually specify binding redirections for all the possible Build Agent machines where the activity might be invoked.
Supplying a configuration file along with the activity and creating an application domain that uses the binding redirections specified in that configuration file seems like an option, but this ultimately would not work, since the "Microsoft.TeamFoundation.Build.Client.BuildActivity" attribute that the activity must be decorated with* would be read by the calling code before the code in the custom activity's assembly is executed - and if the version of the TFS assembly that that attribute came from does not match the version of the TFS assembly loaded in memory, the activity is as good as if it weren't decorated with that attribute at all.
(* I have confirmed that if a custom activity is not decorated with the BuildActivity attribute, the custom activity's type cannot be created and the build fails.)
Removing all references to TFS activities and loading TFS-related types using reflection also seems like another option, but would fail for the same reason, since obviously the BuildActivity attribute cannot be reflectively applied to the class before the code inside the class itself is called by external code.
Since the few TFS types and methods the activity depends on exist in the TFS 2010, TFS 2012 and TFS 2013 assemblies and since the activity is compiled against .NET 4.0, the only reasonable workaround I can think of is to create 3 separate builds: one compiled against the TFS/VS 2010 (10.0.0.0) assemblies, one compiled against the TFS/VS 2012 (11.0.0.0) assemblies, and one compiled against the TFS/VS 2013 (12.0.0.0) assemblies.
(And of course, while I have the TFS2010/TFS2012/TFS2013 versions of the above assemblies on my development machine, the assumption is that the Build Agents will have only the version of those assemblies that comes with its version of TFS.)
The other workaround seems to be to specify binding redirections for all the Build Agent machines, but with a rather large number of Build Agent machines this is not feasible.
Is there an actual solution to this problem or am I stuck having to create 3 builds?
if you go down the route of having 3 assemblies, technically you could create 3 BuildProcessAssemblies folders and add the
Microsoft.TeamFoundation.Build.Client.dll
Microsoft.TeamFoundation.Build.Workflow.dll
Microsoft.TeamFoundation.VersionControl.Client.dll
libraries to each folder, then point each particular controller to the relevant folder.
I have a project that was built for company X. Then they decided to allow company Y to use the product - and they wanted to make some minor branding-type changes. I come from a C programming background, so I added another build configuration that specifies a conditional compilation symbol depending on which brand the solution is being built for. Then the source code has a few:
#if COMPANY_X
// do stuff
#elif COMPANY_Y
// do different stuff
#endif
Now here's my question: Can I use the solution's build configuration to manipulate a single (Visual Studio Installer) setup project? Or do I have to maintain multiple setup projects to manage the differences between them (app name, install folder, manufacturer, etc.)? (Or perhaps more fundamentally, am I going about this all wrong?)
Background info: Visual Studio 2010, Visual Studio Installer, C#
You can use single vs 2010 solution and create multiple solution configurations (ideally for different company or different environments).
VS 2010 Menu --> Build--> Configuration Manager--> Select new from Active solution configuration. Using this approach you dont have to write conditional builds.
Right now I have a WIX 3.5 project that lives in my VS 2010 solution. It works great and compiles down to 1 MSI.
What I want is to have the 1 project potentially compile down to 2 MSI's. One of the MSI's references a .NET 3.5 DLL that it is installing into the GAC, and the other MSI references a .NET 4.0 assembly that it is also installing into the GAC.
That way I can give the .NET respective MSI's to those depending on what framework they are on.
Is this possible?
Depending on your preference, you can either:
In this Solution panel/Project tree, have two separate projects; a .Net 3.5 and 4.0 projects, with the projects sharing files but different includes/build options.
or
Under the Build tab, pick "Configuration Manager" and "New", using the option to copy the current build to a new configuration. This is similar to having a Release/Debug version.
Here's an overview of this option:
MSDN overview of VS Configuration Manager
The advantage of the first method is the solution pane shows clearly that there are two builds (but its sort of redundant). The second is a bit cleaner, but a bit more hidden (and I'm pretty sure, you can only set the active project to build one configuration at a time).
I'm using the Visual Studio Setup project. If I go to the properties of the Setup project, it lets me choose which pre-reqs are required, at which point I choose the C++ Redistributable.
On some systems, this works fine - but recently my users are reporting that the install failed because "A newer version of Microsoft Visual C++ 2010 Redistributable has been detected on the machine."
What's the proper way to do this? Is Visual Studio's detection fouled up somehow and unable to detect C++?
Yuck, this is ugly. I was wondering what would happen after Microsoft gave up on the side-by-side install of the runtime DLLs for VS2010. Seems clear, the interwebs are full of this installer error. The biggest victim seems to be Microsoft itself with Streets and Maps failing to install.
I'm not aware of any security patches for it so I have to guess that you haven't updated to SP1 yet. And your customers use a product of a vendor that did. This is a battle that you're always going to lose some day. Do consider taking advantage of the app-local deployment for the DLLs, copying them in the same directory as your main EXE. Simply copy them from the vc/redist directory before putting the setup package together, no need to tick the prerequisite. You'll need:
msvcr100.dll and msvcp100.dll for the regular CRT
atl100.dll if you use ATL
mfc100.dll, mfc100u.dll, mfcm100.dll, mfc100u.dll if you use MFC (u = Unicode, m = managed)
mfc100xxx.dll where xxx is the 3 letter language code if you use MFC on a non-English machine
vcomp100.dll if you use OpenMP in your code.
Only disadvantage is that they won't get updated if there's a security patch. That could be an advantage too, depending on what color glasses you wear. If you're uncomfortable about it then keeping the machine that creates the setup package updated, including enabling Windows Update, is an important requirement.
The default Visual C++ 2010 Redistributable uses a Product Code for detection. So Visual C++ 2010 SP1 Redistributable is not detected as installed. This is why the package tries to install it and fails.
A good solution is to create your own custom prerequisite which uses a better detection criteria. Here is an article which may help you:
http://blogs.msdn.com/b/astebner/archive/2010/05/05/10008146.aspx
Visual Studio setup projects do not support custom prerequisite creation. However, it can be done by manually generating the required manifests.
You can find the manifests structure here: http://msdn.microsoft.com/en-us/library/ms229223(VS.80).aspx
These manifests can be generated automatically with the Bootstrapper Manifest Generator tool.
After generating the package manifests, you can add all these files (including the package) in a separate folder in the Visual Studio prerequisites folder, for example:
C:\Program Files\Microsoft SDKs\Windows\v7.0A\Bootstrapper\Packages\
This way Visual Studio will show the prerequisite in your setup project properties page.