Can both clients be installed and used at the same time ?
The purpose of using both is based needs to develop for Lync 2010 while still using Communicator 2007 in a corporate environment. Or would a developer be forced to have two different machines/VMs/boot environments ?
No - you can't run both side-by-side. Installing Lync will uninstall Communicator.
However, you can use a registry hack (unsupported, unfortunately) to enable your copy of Lync to run against your OCS infrastructure. This works for R2, not 100% sure about R1.
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Communicator]"DisableServerCheck"=dword:00000001
If you're serious about Lync development, the best solution is to build a server environment specifically for developing against.
Related
I would like to know can we install and configure the windows self hosted agent on Azure Classic Machines? I have already created in ARM machines. I don't have classic machines from my end for testing but having at my client environment. We can't create Classic machines as well now (As it has been deprecated). Before requesting my client, I just want to get some clarity this is possible in the classic machines or not ?
Before requesting my client, I just want to get some clarity this is
possible in the classic machines or not ?
Classic mode is just one deployment model, just as Lex Li commented, the types of virtual machines doesn't matter in your scenario. Only the operating system makes sense for installation of self-hosted agents.
Check prerequisites of self-hosted agent:
Windows 7, 8.1, or 10 (if using a client OS)
Windows 2008 R2 SP1 or higher (if using a server OS)
PowerShell 3.0 or higher
.NET Framework 4.6.2 or higher
Only tips above have effect on the installation and usage of windows self agents. Hope it helps to resolve your puzzle.
I have successfuly run rStudio on Amazon Web Services and it is extremely useful.
I want to run eclipse on AWS as well. When I type this in to google most tutorials are about the eclipse plugin. That's not what I want. I want to run eclipse on AWS.
I tried setting up an instance on EC2 which allowed me to run windows server 2012 but I couldn't install anything because of various internet explorer configuration issues and anyway I hat windows. I also tried a remote linux installation but its not really what I want. I want to run eclipse so that I can access it from a public DNS in the same way that I have managed to do with rStudio. Is this possible. Are there other (even non-AWS) ways?
I presume that by "AWS" you are actually referring to Amazon EC2 virtual machines.
Installing software on an Amazon EC2 instance is no different to installing on any other computer -- it's the same copy of Microsoft Windows you would use elsewhere.
The difficulties you mention of running Internet Explorer on Windows 2012 is entirely part of Microsoft's (rather strange) security settings that discourage using Internet Explorer as a system administrator, in order to combat security weaknesses that people try to exploit. Windows 2012 will no longer be supported by Microsoft in 2018.
I recommend using Windows 2016, which does not seem to impose such restrictions. It's also a newer, supported operating system that matches Windows 10.
Then, just install the software as normal and things will work a lot better for you.
Update:
You're right -- IE has problems on Windows 2016 but they are different to what is happening on Windows 2012 (last time I looked).
To get around the silly Microsoft IE security:
Run Server Manager
Go to Local Server
Click IE Enhanced Security Configuration ("On")
Turn both settings off
Internet Explorer then works and you can install Eclipse.
We have a classic ASP application we just migrated from Windows 2008 R2 to Windows 2012 R2 Core.
Apparently Core versions of windows don't include cdosys or cdonts and thus our application can no longer send email.
Most of the advice I can find suggests using system.net.mail for sending email which of course is a .NET technology and we're using classic ASP.
We do have .NET on our system but I'm not sure if classic ASP could talk to a .NET page for sending email?
Besides using a 3rd party COM utility like Persits ASPEmail are there any native ways of working around this?
We do NOT want to convert the server core instance to the full version of windows. That's killing an ant with a bazooka. This is only impacting two places in our code and everything else works just fine on core.
Unfortunately, CDONTS was superseded by CDOSYS some time ago. When migrating from Windows Server 2008 to Windows Server 2012 I had this exact same issue, but managed to find a fix.
It involves taking a copy of the cdonts.dll file from the Windows Server 2008 Server and adding it to the Windows Server 2012 server then registering it with the relevant COM subsystem without any need to change code or install a 3rd Party library.
Hopefully the same method will work with Core but I haven't tested it.
We're building a web application in VS2010, using the .NET 4.0 FW. Our application includes reports that pull data from our database server.
What runtimes or redistributables do we need to deploy to our web server (Windows Server 2008 Standard)? And where do I find them? Is there anything we need to purchase?
You should use msdeploy tool for your purposes.
Hello I have been fighting some complexities with understanding deployment of Primary Interop Assemblies (PIA) for MS Office. I have Visual Studio Com Add-IN built in VS 2008 on pure com technology (not VSTO see bottom of this for more on that), which references 2003 Primary Interop Assemblies but the add-in may be used on 2003, 2007 or now 2010 Office machines. Because I never know if the customer will be using 2003, 2007, or 2010, I cannot simply deploy one PIA version as a prerequisite (unless I make 3 installers which I do not want to do). Now, my understanding is that when you follow the steps here to add 2003 and 2007 PIA to the prerequisite lists that show up in a Visual Studio (2008) setup package, the prerequisites are smart enough to determine which office version is running on the client you are targeting. So if you were to select 2003 primary interop assemblies and 2007 primary iterop assemblies as both being prerequisites then when this installs on a machine that has 2003 it should be intelligent enough to only try to add the 2003 PIA if those are missing on this machine and if this is a 2007 Office machine then it will only install 2007 PIA (and not try to install 2003 PIA).
Question 1 is this a correct understanding (that the prerequisite packages are this intelligent to only install what it needs based on the version of Office?)
Question 2 is there a way to get the 2010 PIA to show in the list of prerequisites in VS 2008 like 2003 and 2007 do? I do not want to upgrade this project to VS 2010 b/c it is considered a legacy app now with many customers from all around the world using it.
Question 3 Even though the actual assembly references 2003 primary interops, I do not presently deploy those interops with the add-in to the install location. Instead, I am assuming that if I can get the correct PIA installed then I don't need this present in the installation path, since the PIA would be in the GAC. However, one possible approach may be to just include the 2003 assemblies that are referenced (in my case excel and word) in the install path and not worry about the PIA. I suspect this would work on 2003 machines but perhaps not on 2007 and 2010 machines b/c on the latter, even if the 2003 interops that are referenced are found at run time in the install path of the assembly, I think if there is not a Policy.11.0.Microsoft.Office.Interop.Excel/Word(etc) in the GAC, then 2007 and 2010 will likely not know what to do with the 11.0 (2003) interops (as I think the Policy.11.0.Microsoft.Office.Interop files redirect requests for the 2003 interops to 2007 or 2010). Any thoughts on this?
Question 4: There is a well known bug with Framework 2.0 apps Office Add-Ins and Office 2003 where the add-in won't load. This was addressed by KB907417 aka KB908002. Dopes anyone know if this KB necessary if you develop on the 3.0 or 3.5 framework (and make 3.0 or 3.5 a prerequisite) since this problem was specific to framework 2.0? Or does the KB still need to be deployed b/c it's office 2003 that is the problem and not the version of the framework?
As you can tell by my 3 questions what I am trying to ascertain is whether we can build one single installer via the VS setup utility. If the PIAs can be done with one installer but the KB above is the obstacle (as perhaps the answer will come back that even on the 3.0 or 3.5 framework 2003 customers will need the KB) then maybe the path to one installer is to just make the KB a prerequisite across the board and install it on 2007 or 2010 machines, though they technically do not need them. Any thoughts on that option would be appreciated as well. Finally, I am aware that writing a manged Com Add-IN for excel or word is now generally done with VSTO instead of pure managed framework code, but this is not an option presently to change the legacy app to this direction. Also it is reported that the 4.0 framework now can be used to deploy add-ins without making any PIA a prerequisite but again, this is not a viable option right now.
Does the code use any Office 2007+ methods or classes? If not, are you sure you cannot use the 2003 PIAs in all cases? The later apps should be backward-compatible (supporting the same API) so the only reason you'd need an updated PIA is if you needed to access some feature added by 2007 or later, I think.
You may want to take a look at Add-in Express, which promises a one-for-all-versions installer, and is pretty easy to use.
As you can tell by my 3 questions what I am trying to ascertain is whether we can build one single installer via the VS setup utility
You cannot. You must create custom installer packager (setup bootstrapper).
Many years ago I used dotNetInstaller with HTML GUI builder, today WiX toolset would be better solution, I think.
Check how PIA .msi installers are constructed with Orca or .msi and .exe installers flow checking windows installer logs.
Based on registry checks, file checks, installed product checks, windows versions, office versions you can create conditions whether component should be installed or not.
Oh and I advise making plugin installers without prerequisites and installing them conditionally with your custom installer bootstrapper.