I am using TFS 2010 and visual studio 2012.
I have created a C# api to connect to tfs. The code works. I used couple of microsoft.foundation dlls. They are using version 2.0
But I had to configure my application pool in IIS on my server (windows server 2008 64-bit) by setting Enable 32-bit applications to True.
The production server doesn't like the 32 bit and is acting up. The dlls can't be used.
I must find the equivalent 64 bit. Can someone point me to where I can find them?
Thank you
#sudhir3, thank you for your suggestion.
Like I said, the code is not an issue and it works, but that involved setting the 32 bit flag on the app pool.
Further investigations lead me to know that there is no equivalent of 64 bit for the 32 bit dll. VS itself is still 32 bit. No near conversion by microsoft to 64 bit is near.
So, I I ended up leaving the IIS 32 bit flag in the app pool set to false and created web api webservice that passed values to a powershell cmdlet, which in turn executes my TFS api code.
Related
Long story, so please bear with me.
I have an app that I wrote back in 2001 for an AS400/iSeries ISV. Basically, it takes drawing commands off of the AS400, and creates a windows graphic (bmp) file so that they can then display the graphic in their application. Everything has worked great over the years. Now, they have a new customer that is having problems running the application. The problem is that when my application is called from the ISV's software, windows generates a message stating that the application is a 16 bit application and can not be run. I am sure that the application is a 32 bit application. We have tested this on 3 machines running Windows 10 x64 at the ISV's office and do not get the error. We get the graphic and everything runs as intended.
I am guessing that the problem is that the WOW64 layer is somehow not enabled or not setup. Questions:
I thought that VB6 apps were all 32 bit. Is that correct?
Is it possible to not install the WOW64 layer during a Windows setup?
Is it somehow possible in Windows 10 x64 to not enable 32 bit apps?
If you have any other suggestions, we are glad to hear them.
TIA and for your time.
Wally
I'm trying to debug an ASPNET Core/EF Core website hosted on Azure. When I try to attach the debugger in VS 2015, via Cloud Explorer, I get this error message:
Yet when I check the site in the Azure portal, it sure seems like it's 32 bit and set to enable remote debugging:
So what am I missing or doing wrong?
Portal setting controls the bitness of the IIS w3wp process. But ASP.NET Core runs in its own process, so that setting has no effect on it. Instead, what determines whether your .NET Core process runs as 32 or 64 bit is how you publish it.
Given that apparently your Core project is published as 64 bit, you might want to try switching the Portal setting to 64 bit. This will affect the debugger MSVCMON.exe process, which should then allow you to attach.
I have inherited a classic ASP project and a VB6 Component (ActiveX .dll) that goes with it.
I would like to be able to debug this component by running it locally on my machine.
I have a Windows 7 Home Premium (64 bit) laptop.
I have setup IIS 7.5 locally (production is running IIS5), however, when I browse to the site (locally) I get:
Active Server Pages error '00000000'
Create object failed
?
An error occured while create object 'OBJECTNAME'
Microsoft VBScript runtime error '800a01ae'
Class does't support Automation: 'ID of object in global.asa
I'm not a server guy, so I don't have a lot of experience setting up IIS. I want to setup this project locally so I can step through the COM object using the debugger.
What do I need to do to get this running?
Just as an FYI :
In the global.asa I have the following:
<object runat="server" scope="session" id="ABC" progid="prjABC.clsABC"></object>
Then in the ASP I have the following call:
if ABC.propertyName = True then
...
It fails at that line.
Sounds like the application pool your site is running in is configured for 64-bit mode (the default).
Switch it to 32-bit by right clicking on the pool and choosing Advanced Settings:
Set Enable 32-Bit Applications to True.
You might also want to configure the Managed Pipeline Mode and set that to Classic, not all Classic ASP apps are happy running in Integrated mode.
If all you need to do is debug the component it may be easier writing a COM Application that uses this COM component. Especially if you have the source to the component you can launch your test application from your vb6 component project as your debug application.
Since it's VB6 though you may have to set up a XP virtual machine to be able to run visual studio 6.0 (I've never been able to get 6.0 working on windows 7). Either that or upgrade the component to visual studio 2010.
If you want to run 32 bit components in a 64 bit environment, you can do it. The trouble with setting IIS to allow running 32 bit components as described above is that you end up having all of iis running 32 bit - which if it's a webserver means the main app you're running is 32 bit so reduces the speed advantage of a 64 bit machine.
To run a 32 bit component in a 64 bit IIS, you need to put it in Component Services. Start->Run->"comexp.msc" runs component services. Then just expand down the tree until you find COM+ Applications, and create a new empty application (with all the defaults set as are). Then expand that application and right click on components and then "new">component. The install new component and select the DLLs. This should allow a 64 bit component to just use the 32 bit ones.
I'm having a lot of trouble getting SharePointRS_x64.msi to install sucessfully says it cannot find sharepoint when in fact that sharepoint is installed and running on Win 7 Pro. Because of the operating system I am unable to install the prereq package that comes with SharePoint Foundation 2010 (which includes this reporting addin).
I already have a reporting server set up for my MSSQL2008 instance(win 2008 server R2). It's working when I go to the http:\servername\Reports i'm able to launch the report builder and everything works. I'm now having trouble setting up the other end on SharePoint (different (developement) machine - running win 7 pro).
Any Help would be GREATLY appriciated.
Please let me know if what I want to do is possible.
Thanks,
Mike
I found the solution.
You need to open config file:
C:\Program Files\Microsoft SQL Server\MSRS10.\Reporting Services\ReportServer\rsreportserver.config
In this config find string:
Add Key="SecureConnectionLevel" Value="2"
Change value 2 to 0.
Values meaning:
3 - Most secure-Use SSL for absolutely everything.
2 - Secure-Use SSL for rendering and methods that pass credentials but don't insist on it for all SOAP calls.
1 - Basic Security-Accepts http but rejects any calls that might be involved in the passing of credentials.
0 - Least Secure-Don't use SSL at all.
You have to remember that installing sp2010 on your desktop is going to limit your farm. It is not going to be a fully functional farm. Advanced features like search and user profile sync will not work/get buggy. I guess now, you can add reporting services intergration to the list of things that don't work. Safe your self a lot of trouble but building a vm, which is going to be closer to your production environment anyway.
UPDATE
I thought it might not be supported by Foundation, but it is:
http://msdn.microsoft.com/en-us/library/bb326356.aspx
I know that there are issues with the VFP OLEDB provider on 64 bit machines. ... but what issues do you encounter while actually running a VFP application - on a 64 bit machine? Has anyone had any experience in this area?
My first thought was that it would just run as a 32bit app, without making use of the 64 bit power. However, I ran into difficulties with a FoxPro application connecting to a SQL Server database (probably an OLEDB issue as well). Are there other issues as well?
This is somewhat of a specialized scenario, and it may not be related to 64 bitness, but since you asked...
My organization recently hosted a legacy VFP 7 app on a Windows Server 2008 Enterprise 64 bit server for access over Terminal Services. The app runs fine, but there is some kind of bug with the TS Easy Print technology. When you print from the app to a redirected client printer over Easy Print, the top, left, and bottom sides of each page of the document get clipped. The workaround we use is to have the users print to pdfFactory on the server first, then print from pdfFactory to the redirected client printer over Easy Print. Works great.
This is somewhat of a stab in the dark...but I believe there are some drivers with MDAC that aren't available in x64 windows. I think you may be able to install the normal 32-bit MDAC but it will install to the x86 folder.
We've seen zero problems with our VFP9 apps on 64-bit XP, Server 2003, Vista, or Server 2008.
Our print engine is a VB DLL though, so we wouldn't run into any VFP-specific printing issues.