I have a C# program which I made in Visual Studio. When I right click on my program executable in Explorer and click Properties>Details it says "Copyright © Hewlett-Packard Company". To troubleshoot I then created an empty Console Application, and it has the same copyright message.
Does anyone know how to fix this? I have tried some tutorials about regedit but they did not work.
Check out the Assembly Information dialog in your project properties.
In Solution Explorer you can right click on your project and select Properties. An Assembly Information button is in the Application tab.
I haven't tried this, but to change the default value, use regedit to modify
HKLM\Software\Microsoft\Windows NT\CurrentVersion\RegisteredOrganization
HKLM\Software\Wow6432Node\Microsoft\Windows NT\CurrentVersion\RegisteredOrganization (x64 systems)
The answer by #Louis is correct. I'm just posting this to add some background information, and to vent my frustration at Hewlett-Packard for creating this stupid situation.
If you buy a Hewlett-Packard PC with Windows pre-installed (which is typical, unless you're in the IT dept. of a company that wipes the hard disk and installs a preconfigured disk image) then Hewlett-Packard has stupidly installed Windows with their name as the owner and owning organization.
Here are some links. I'm surprised there aren't even more frustrated customers complaining about this.
https://www.besttechie.com/forums/topic/11774-change-the-name-of-the-registered-owner-on-an-oem-machine/
https://www.groovypost.com/howto/howto/change-the-registered-owner-and-company-name-in-windows/
- see the comments
https://social.msdn.microsoft.com/Forums/sqlserver/en-US/12fdb09b-472b-4634-991c-670e5f775365/upon-new-project-hewlettpackard-is-always-placed-in-the-assembly-company-name-field?forum=visualstudiogeneral
https://support.hp.com/in-en/document/bph05548
- is obsolete, doesn't include x64 registry entry
So the solution is to do this, as soon as you power up the new HP machine (otherwise this owner information will "pollute" all the programs you install):
Fix the RegisteredOrganization and RegisteredOwner registry information at HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion
If it's an x64 machine (and all machines are now), also fix the RegisteredOrganization and RegisteredOwner registry information at HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Windows NT\CurrentVersion
I'd imagine you're looking for the AssemblyInfo.Copyright Property. In order to modify this simply find the assembly.info class and modify it appropriately.
If you can't find it you can also use the Assembly Information Dialog as suggested by #Louis, which modifies the file for you.
Related
I have created outlook addin for Outlook 2013 64 bit.
In that Addin, i have created Form region with custom controls.
Then with the reference of http://blogs.msdn.com/b/emeamsgdev/archive/2013/11/21/outlook-deploying-an-outlook-2013-add-in-using-installshield-le.aspx i created setup file for Addin.
Now i installed it in my computer and everything works fine.
However when i try to install it on client computer, it doesn't show addin in outlook.
and i am not able to find any reason.?
I have also created registry for my addins
If it simply doesn't load, without errors, it only means one thing, outlook is unaware of your addin, cause even when addins are not working, outlook gives you an error or turns the LoadBehaviour regkey to '2'.
On your client, you should check that the registry values are set properly.
**HKEY_CURRENT_USER\Software\Microsoft\Office\Outlook\Addins\Outlook_PROJECT_ADDIN
If your addin doesn't work, check to see if those values exist, and if they do, what happens when outlook loads ? does LoadBehavior turns to '2' instead of 3 ?
If so, and it works perfectly on your pc, it probably means you have issues with the Manifest regkey, make sure the manifest points to a valid local location followed by a |vstolocal
so its syntax should be something like:
file:///C:/Outlook_Proj.vsto|vstolocal
Also make sure you have .Net Framework v4.0 installed on your target PC.
If you're trying to install it to a network drive, make sure you remove the '|vstolocal| thingy, and add the network drive to the trusted zone in Internet Explorer Settings.
Hope the following steps will help you solve this problem if you are still facing it.
Run the deployed setup with administration rights.
If it is not shown under Add-ins, open the setup folder and double click on the .vsto file then select install.
If you can see the addin among the others, and is not functioning it means it is disabled. To enable the add-in(since you are using outlook 2013), go to File -> Slow and Disabled Add-ins, and you shold see your add-in on the pop-upped window. Enable it.
Create the VSTO_SUPRESSDISPLAYALERTS = 0 enviorment variable to get any VSTO alerts. Take a look in the Windows event viewer and off course be sure of being installed the pre requisistes like Office Primary assembles and VSTO for office. Another think, check if your adding was not crashed once and move to inactive add-in list. Search registry for Resiliency key.
On one computer 'A' (win vista 32 bit) if I run my program in debug mode all the richtextbox controls throw 'property cannot be set' errors.
I can go on to build the exe (without error ) and the full application OK
But when I then install and run the application on this computer or on computer 'B' (win xp) the same problems occur on both.
However if I run the exact same code in debug mode on computer 'B' there are no errors.
If I build and install the application on computer 'B' it works fine. If I then install this application on computer 'A' it also works fine.
When putting together the application for distribution, both computers use identical copies of richtx32.ocx (it, like the code, is checked out from the same repository).
If I check out previous copies of the code on computer'A' (that used to previously behave OK) they also now exhibit the same problems as the latest version of the code.
I don't have a clue what's going on, please help!
I'm seeing multiple references to the Property cannot be set message being resolved in the version of the Rich Text Control that is distributed in Visual Studio 6.0 Service Pack 4, and another Property cannot be set message fixed in SP5.
First and foremost, make sure that a minimum of SP5 is installed; I'd just go with SP6.
For reference, my Microsoft Rich Textbox Control 6.0 (SP6) is at C:\Windows\System32\RICHTX32.OCX, and is version 6.1.97.82.
I know you said that both machines have the same copy of the control installed; for the sake of completeness, you may want to double-check that the new control was registered after installation.
EDIT:
I exported the HKEY_CLASSES_ROOT\CLSID\{3B7C8860-D78F-101B-B9B5-04021C009402} reg key:
Windows Registry Editor Version 5.00
[HKEY_CLASSES_ROOT\CLSID\{3B7C8860-D78F-101B-B9B5-04021C009402}]
#="Microsoft Rich Textbox Control 6.0 (SP6)"
[HKEY_CLASSES_ROOT\CLSID\{3B7C8860-D78F-101B-B9B5-04021C009402}\Control]
[HKEY_CLASSES_ROOT\CLSID\{3B7C8860-D78F-101B-B9B5-04021C009402}\Implemented Categories]
[HKEY_CLASSES_ROOT\CLSID\{3B7C8860-D78F-101B-B9B5-04021C009402}\Implemented Categories\{0DE86A52-2BAA-11CF-A229-00AA003D7352}]
[HKEY_CLASSES_ROOT\CLSID\{3B7C8860-D78F-101B-B9B5-04021C009402}\Implemented Categories\{0DE86A53-2BAA-11CF-A229-00AA003D7352}]
[HKEY_CLASSES_ROOT\CLSID\{3B7C8860-D78F-101B-B9B5-04021C009402}\Implemented Categories\{0DE86A57-2BAA-11CF-A229-00AA003D7352}]
[HKEY_CLASSES_ROOT\CLSID\{3B7C8860-D78F-101B-B9B5-04021C009402}\Implemented Categories\{40FC6ED4-2438-11CF-A3DB-080036F12502}]
[HKEY_CLASSES_ROOT\CLSID\{3B7C8860-D78F-101B-B9B5-04021C009402}\Implemented Categories\{40FC6ED5-2438-11CF-A3DB-080036F12502}]
[HKEY_CLASSES_ROOT\CLSID\{3B7C8860-D78F-101B-B9B5-04021C009402}\Implemented Categories\{7DD95802-9882-11CF-9FA9-00AA006C42C4}]
[HKEY_CLASSES_ROOT\CLSID\{3B7C8860-D78F-101B-B9B5-04021C009402}\InprocServer32]
#="C:\\Windows\\system32\\RICHTX32.OCX"
"ThreadingModel"="Apartment"
[HKEY_CLASSES_ROOT\CLSID\{3B7C8860-D78F-101B-B9B5-04021C009402}\MiscStatus]
#="0"
[HKEY_CLASSES_ROOT\CLSID\{3B7C8860-D78F-101B-B9B5-04021C009402}\MiscStatus\1]
#="131473"
[HKEY_CLASSES_ROOT\CLSID\{3B7C8860-D78F-101B-B9B5-04021C009402}\ProgID]
#="RICHTEXT.RichtextCtrl.1"
[HKEY_CLASSES_ROOT\CLSID\{3B7C8860-D78F-101B-B9B5-04021C009402}\Programmable]
[HKEY_CLASSES_ROOT\CLSID\{3B7C8860-D78F-101B-B9B5-04021C009402}\ToolboxBitmap32]
#="C:\\Windows\\system32\\RICHTX32.OCX, 1"
[HKEY_CLASSES_ROOT\CLSID\{3B7C8860-D78F-101B-B9B5-04021C009402}\TypeLib]
#="{3B7C8863-D78F-101B-B9B5-04021C009402}"
[HKEY_CLASSES_ROOT\CLSID\{3B7C8860-D78F-101B-B9B5-04021C009402}\Version]
#="1.2"
[HKEY_CLASSES_ROOT\CLSID\{3B7C8860-D78F-101B-B9B5-04021C009402}\VersionIndependentProgID]
#="RICHTEXT.RichtextCtrl"
A bad richtx32.oca file in the system32 directory seems to have been the cause of this.
Here's what an .oca file does:
Some of the properties of the control are provided by the framework
and some by the control itself. Programmatically, the properties from
the framework and the control all appear as properties of the control.
In order for these properties to appear, Visual Basic creates an
extended type library when the control is loaded into the toolbox.
Because the process of reading the control's type library and creating
the extended type library is time consuming, Visual Basic caches the
extended type library information into an OCA file.
If you delete the OCA file for a control Visual Basic recognized,
Visual Basic will recreate the .OCA file when you load a project
requiring the control. This recreation process comes with a time
penalty.
So it seems that having a bad .oca file in existence can mean that the properties of the control both in the IDE and in the compiled .exe will be affected.
The solution is to delete the .oca file in the system32 folder and then load the project again.
My Outlook addin MSI installs the addin (It is listed in Add\Remove programs) but sends it straight to inactive application addins.
How can I fix this?
Check the LoadBehavior key value for your plugin.
HKEY_CURRENT_USER\Software\Microsoft\Office\Outlook\Addins\%your add in%\LoadBehavior
If you see the registry hive for you add-in - it's most likely to be installed correctly.
The LoadBehavior value should be 3 before you start Outlook. If it's not, set it to 3.
If it goes to 2 when you start Outlook - it is definitely trying to run it, so it's good news in a way.
You will need to do some diagnostics there - try instantiating your add-in from vbs
set c = CreateObject("EnthusiasticDeveloper.OutlookAddIn")
This should give you no errors.
If it doesn't and the object is instantiated - you need to put diagnostics in your add-in.
It is being called by Outlook and your most likely to get enough control to instantiate log4net.
HTH
It seems the MS Outlook started evaluating the add-ins that directly affect product overall performance and set them as inactive. I found this article that indicates the windows registry entry for DisabledItems (HKEY_CURRENT_USER\Software\Microsoft\Office\14.0\Outlook\Resiliency\DisabledItems). It is much likely to your add-in be listed on this folder. Backup the related entry before removing it.
See detailed information on this accessing:
http://www.outlook-apps.com/inactive-outlook-add-ins/
Cheers,
Vieira
This probably happens because the load behavior is not set correctly. This article can help you: http://msdn.microsoft.com/en-us/vsto/ff937654.aspx#Create
I'm fighting with VS 2010 and this error that seems to be very common in previous versions, but it looks like not everyone is having it in the latest version.
I've got VS 2010 SP1 and I'm getting this error quite often.
The problem is that it's not even enough to restart VS in order to make it go away, I usually have to restart my PC, and I'm losing a lot of time doing this (it's quite frequent)
I've got Windows 7 32bits (can't upgrade to 64 bits, the company doesn't allow it), and I can't do things like creating another solution (please don't reply this :) )
I've used the command to make devenv.exe LARGEADDRESSAWARE, but the error keeps on happening.
My virtual memory size is set to automatic, and the weird thing is that VS doesn't even take 2GB of ram, so I don't know if the error is really because it's lacking memory, or if it's some bug in the program
Any ideas, things to try, something?
I tried everything else as well. The problems continued to come back until I tried
http://blog.rongabriel.com/2010/03/08/not-enough-storage-is-available-to-process-this-command/
Edit: Link is dead, archived version: http://web.archive.org/web/20100929160038/http://blog.rongabriel.com/2010/03/08/not-enough-storage-is-available-to-process-this-command/
Click on Start > Run > regedit & press Enter
Find this key name HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\LanmanServer\Parameters
Locate IRPStackSize
If this value does not exist Righ Click on Parameters key and Click on New > Dword Value and type in IRPStackSize under the name.
The name of the value must be exactly (combination of uppercase and lowercase letters) the same as what I have above.
Right Click on the IRPStackSize and click on Modify
Select Decimal enter a value higher than 15(Maximum Value is 50 decimal) and Click Ok
You can close the registry editor and restart your computer.
This can be found under MS KB https://support.microsoft.com/en-us/kb/285089
Have a look at
Visual Studio 2010 -- how to reduce its memory footprint
I think I got the best results when I turned off C++ headers index. YMMV
Check the output project type in properties. In my case it was changed to "Windows Application" though it was a "Console Application".
Switching back to console application solved my problem.
I have a very simple VS2005 deployment project that aims to install for all users on a PC.
All the application files are written to %Program Files%\MyProg. A shortcut is created in the start menu and the startup folder. No registry settings or anything else are created. I have set
'InstallAllUsers' to true.
The created MSI runs fine and installs the software. It works without any problems when running under the user account from which it was installed.
When logging in as another user, the start menu and startup icons are present. It attempts to launch the application however an installation window pops up and states that 'the feature you are trying to use is on a network resource that is unavailable.' The installer will only proceed if pointed to the original MSI file.
Why does this happen? I want my application to be installed completely for all users when it is installed by a single user.
edit: Solution
I was getting similar event log messages as shown on this page. In my case it turned out to be as simple as ensuring that the User's Program Menu had its 'AlwaysCreate' attribute turned to false. If it was true, windows would try and recreate the folder when a new user logged in. This somehow required the invocation of the installer and thus resulted in the 'please insert the installation media' prompts.
It is actually kind of hard to say without some more information. I would recommend checking on the rights in the installed folder (seeing if only the one who installed it has rights) and also checking the file list for the directory (to make sure VS didn't automatically place some files in the user profile). Let me know what comes out from those two steps and we can try to keep digging if that didn't shed any light on it.
Keep in mind chances are this is most def not specific to Visual Studio, look at this MS support article here where the same message is coming back for office.
I know this is an old post but I thought I'd add another cause and solution in case the above didn't work for you.
There is a bug in VS Setup and Deployment Projects which results in registry values being entered into HKCU instead of HKLM irrespective of the InstallAllUsers property being set to true.
You must use Orca msi editor to change the registry root for "DesktopFolder" and "ProgramMenuFolder" from either 1 or 2 to -1. The issue cannot be resolved via VS.
http://www.qa.downappz.com/questions/vs-2010-deploys-per-user-features-during-install-which-require-access-to-install-media.html