I would like to have Visual Studio sign my assemblies.
I got past the point where I can specify my PFX file without any complaints. That was not easy, as I had two of errors. Yes, I had to make sure that I used openssl (a stackoverflow article helped with that error) and a microsoft article helped with the first error message, where I had to import the PFX file, clear/set options, and then reexport to not include downstream certificates.
When I go to build a project, I receive the warning:
Option 'keycontainer' overrides attribute 'System.Reflection.AssemblyKeyNameAttribute' given in a source file or added module"
Naturally, my assembly did not get signed.
I did some research and the best suggestion that I saw was to add a line to the project file (did not help) or to sign stuff manually using a post build event, which I am now doing, but I would still like to get the sign tool to work.
I cannot imagine that Microsoft would offer the Singing tab, if the vast majority of developers would not be able to use the feature.
Heck, with the new Visual Studio 2012 Update 1 release, I would have expected that signing assemblies (DLLs or EXEs) would be child's play. The task is anything but.
Thoughts?
Without more information, I can't tell if this will fix your issue. But I'll post the answer that worked for me. In my case, I had converted an old project (pre VS 2012) that had specified signing in the AssemblyInfo.cs file like so...
[assembly: AssemblyDelaySign(false)]
[assembly: AssemblyKeyFile("")]
[assembly: AssemblyKeyName("")]
I usually use the Signing tab in project/properties as you describe. The warning message was essentially saying "Hey, you already told me something different in the source code!"
The solution for me was to remove the above three lines in the AssemblyInfo.cs file.
I realize this is probably way after your original post but I hope someone finds it useful.
Related
today I created a new Project, using Catel Framework in Silverlight.
However - I am facing a Problem when generating the service-Client for the WCF-Service in the silverlight Project.
To reproduce the issue:
- open solution,
build
"Show all files" in the Silverlight Project (CatelWCF.Problem)
Observe:
beneath node "WCFService" in Reference.cs - all Code generated successfully
now "configure service-reference" (right click "WCFService", Configure)
choose radio-button Option "Reuse types in all referenced assemblies", followed by OK (before it was configured to use all but Catel.Core)
Observe:
error-message in Error-List
view file "Reference.cs" - it is empty.
In WPF there is no Problem whatsoever, even if all assemblies are referenced. (CatelWCF.Problem.WPFClient Project)
Any ideas?
Johannes Colmsee
Update:
Sorry, the demo-Project can be downloaded here:
Demo
Update2: About why "observe" #1 Shows a succesfully generated file: "Catel.Core.dll" is explicitly excluded from referenced assemblies when you open the Project.
I narrowed down the Problem to one specific type in Catel.Core dll - Geert, please check what is wrong with this class:
Catel.Runtime.Serialization.Xml.XmlSerializationContextInfo
Regards
Johannes Colmsee
Update: Creating a sample Project with a (almost exact) copy of that class - no Problems.
After upgrading my cloud projects to Azure SDK 2.6. (via button in project properties window), everything works just fine, except I am getting like hundred of these warnings for *.cscfg files:
The complexType 'http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceConfiguration:AccessControlElement' has already been declared.
The complexType 'http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceConfiguration:AddressAssignmentsElement' has already been declared.
The complexType 'http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceConfiguration:Certificate' has already been declared.
etc. for many more elements.
Already tried Clean, Rebuild, close-open VS... with no success. It doesnt affect functionality of the project, but it is really annoying to have Error list full of these things.
Any idea what is wrong and how to fix it?
OK, so guys from MSDN forums helped me solve this one.
Check SchemaVersion value in service definition file, it should be "schemaVersion="2015-04.2.6" (this one was OK for me)
Open service definition file as XML, right click on it, Properties -> Schemas. In the window (see pic), leave only ServiceDefinitionSchema26.xsd checked ("use this schema"), set all other versions to Automatic (unechecked). Restart Visual studio and warnings are gone.
I tried to google. Microsoft Connect doesn't accept bugs for Service Bus. Azure Portal sends to either MS forums or to StackOverflow - so here I am.
The question is really in the title: how do I report a bug with Service Bus?
(not the Azure version, but the one you install on premises)
And here is the issue:
Microsoft.Cloud.ServiceBus.dll has a reference to Microsoft.Cloud.Common.AzureStorage.dll. It uses one type from that assembly - namely, StorageAccountInfo. It's part of a configuration section (namely, NamespacePolicyDataStoreFactorySection.Parameters.BlobStorageAccountInfo), but apparently only makes sense in the Azure environment, and never used in the on-premise scenario.
But here's the catch: Microsoft.Cloud.Common.AzureStorage.dll is not actually shipped with Service Bus 1.1. I tried to find it in various SDKs and Azure toolkits, samples and whatnot (of which I have plenty), as well as online - and found zippo information about that DLL or where to get it. This is the only place I found a mention of it.
Despite being a WTF in itself, the absence of DLL does not really prevent anything from working: the type is not actually touched by any code in the on-premise scenario, so no complaints.
But here's the second catch: mscorlib.dll v4.6.7.0 (which came with VS2015 CTP5) has a slight change compared to the previous version, 4.0.30319.34014, - in System.Attribute.InternalGetCustomAttributes(PropertyInfo,Type,bool), more precisely, this line. That line did not exist in the previous version of mscorlib, and everything was fine. But now it does exist, which leads to the property type being touched, which leads to loading the DLL, which fails, because DLL is not there.
So the whole process starts with loading configuration section NamespacePolicyDataStoreFactorySection and works like this:
ConfigurationManager.GetSection ->
... ->
BaseConfigurationRecord.GetSectionRecursive ->
... ->
BaseConfigurationRecord.CallCreateSection ->
MgmtConfigurationRecord.CreateSection ->
ConfigurationElement.Reset ->
ConfigurationElement.get_Properties ->
ConfigurationElement.PropertiesFromType ->
ConfigurationElement.CreatePropertyBagFromType ->
Attribute.GetCustomAttribute (for property BlobStorageAccountInfo of type StorageAccountInfo) ->
... ->
Attribute.InternalGetCustomAttributes(PropertyInfo) ->
Attributes.GetIndexParameterTypes ->
RuntimePropertyInfo.GetIndexParameters ->
... ->
RuntimeMethodInfo.GetParameters ->
... ->
kaboom! (touches the return type, tries to load DLL containing it, fails)
Some (futile) attempts at a workaround
Remove the configuration section from config. Unfortunately, Service Bus is not very fault tolerant in this respect: fails with NRE when section is not present. It is also impossible to provide an alternative config section "handler", because in the .NET config system "handler" and "data" are the same thing.
Provide a fake DLL with the needed type. Can't do that, because everything is strongly named.
Find the missing DLL somewhere. Tried that and failed. There are no mentions of the DLL on the web, let alone the bits.
A careful reader may ask: whoa, wait a minute! VS2015 CTP5?! Are you saying you installed pre-release software on a working machine?! Well then, of course it doesn't work, what did you expect? That'll teach you to be the early adopter!
And the careful reader would be absolutely correct: totally my fault, I knew potential dangers, I did it anyway, serves me right.
But that's not the point. My installing pre-release software doesn't diminish the WTFness of referencing a DLL, but not shipping it. While I personally will be fine, I just want to make sure this doesn't suddenly stop working when .NET 5 is released and hits Windows Update.
I know it's a late answer to the question and it is actually not the answer to the question asked, but today, after installing VS 2015 RC on a PC with Windows Service Bus 1.1 and restarting the PC, my service bus gateway service stopped working and I went through all the pain described in this question but finally could make a solution out of the fake assembly scenario. Here's the solution:
Created the fake assembly Microsoft.Cloud.Common.AzureStorage.dll with version 2.1.0.0 and signed it with a new key file.
Disassembled it using: ildasm /all /out=azurestorage.il Microsoft.Cloud.Common.AzureStorage.dll
Extracted the public key and public key token from another Microsoft.Cloud.* assembly located in service bus folder by ildasm /Tp Microsoft.Cloud.Common.Diagnostics.dll
Opened azurestorage.il in a text editor and changed the public-key token and public key with the ones extracted in the last step
Reassembled the il file: ilasm /dll azurestorage.il /out=Microsoft.Cloud.Common.AzureStorage.dll
Registered the assembly for signature verification skipping using: sn -Vr Microsoft.Cloud.Common.AzureStorage.dll
Installed the resulting assembly to GAC: gacutil /i Microsoft.Cloud.Common.AzureStorage.dll
and it finally worked. Hope this helps anyone who got stuck in this problem.
As given in this answer by Jafin there is fortunately an official fix from Microsoft release 10/23/2015 that solves the issue with .NET 4.6.
Download here: Update for Service Bus Server 1.1 (KB3086798)
as I understand what you need is reporting a bug to Microsoft, and I found out you need to report a bug to Microsoft. Its good to know microsoft will aapriceate users who report bugs.
According to Microsoft answer you can reporting Microsfot bugs here:https://connect.microsoft.com/
note: You must have an microsoft account, you can make it at hotmail.com
And I know some of microsoft products are not there like outlook.com
First go to https://connect.microsoft.com/ :
STEP BY STEP
i.stack.imgur.com/CewDL.png
Step 1: Write the program what you like to report a bug about it, and then click on join.
i.stack.imgur.com/pJbQY.png
Step 2: Click on continue.
i.stack.imgur.com/cCgXq.png
Step 3: Make up your profile.
i.stack.imgur.com/PVqXi.png
Step 4: Click on feedback.
i.stack.imgur.com/nL5Kr.png
Step 5: Write the bug title on text box at the end of page.
i.stack.imgur.com/gEOJG.png
Step 6: Then click on submit feedback
i.stack.imgur.com/MQgV0.png
Step 7: Now you can write the problem and tell Microsoft about this bug.
During web application creating i got below popup message:
"Visual studio does not have permissions to read the template information from the registry. this is often caused by registry permission problem."
Any one have any solution?
Please help me. i wana to see Visual Studio new features.
Thanks
this might be quite late as an answer, but I excpierienced the same problem and I found the solution on a msdn page : here is the original solution message :
I came across this issue with Visual Studio 2010 and Windows 7. I did not find this problems source as of yet but, I have found many Visual Studio users encountering it. I tried Michael's solution to this problem and it did more damage then anything else. It even went as far as to make Visual studio to boot into "Shell mode" and tell me the registration was not valid.
Using System Restore I rolled back the changes made by the subinacl tool and Michaels script (it probably was not meant for Windows 7, causing the errors in the first place) .
being a long time visual studio user and a pretty good trouble shooter, I knew the subinacl was the proper tool to correct the problem, but the script was incorrect for my perticular setup. I adjusted the script as follows: (this is a batch script)
cd /d "%programfiles% (x86)\Windows Resource Kits\Tools"
subinacl /subkeyreg HKEY_CLASSES_ROOT\VisualStudio* /setowner=domain\user
subinacl /subkeyreg HKEY_CLASSES_ROOT\VisualStudio* /grant=everyone=f
/grant=administrators=f /grant=system=f
pause
I tried to include the "setowner" command with the grant commands (on the same line) but it would throw errors all the time.
This script fixed MY "Requested registry access is not allowed" with Windows 7 and Visual Studio 2010.
if you want to try this script: Follow Michael's instructions, but use the script provided in this post and replace the "domain\user" with the proper credentials. You may also need to change the Path of Windows Resource Kits if you installed it in a diffrnet place or are not using a 64 bit OS. Before using this script please backup your registry.
I hope that that helped!
*the original web page was : http://social.msdn.microsoft.com/Forums/en-US/c273b0e1-7f46-4065-afaf-4edf285d2531/vista-wpfapplication-requested-registry-access-is-not-allowed
I had this problem too. Followed the post by user2698666 without success. Stuck Process Monitor on it and found there were more registry entries causing a problem called WDExpress. Thought I'd post my fix incase anyone else has same problem:
subinacl /subkeyreg HKEY_CLASSES_ROOT\VisualStudio* /setowner=domain\user
subinacl /subkeyreg HKEY_CLASSES_ROOT\VisualStudio* /grant=everyone=f /grant=administrators=f /grant=system=f
subinacl /subkeyreg HKEY_CLASSES_ROOT\WDExpress* /setowner=domain\user
subinacl /subkeyreg HKEY_CLASSES_ROOT\WDExpress* /grant=everyone=f /grant=administrators=f /grant=system=f
I had the problem with Visual Studio 13, where i wanted to add a webtest project for my newly created solution.
Tried the above trics to set ACL but it didn't work.
Finally used the Procmon.exe to locate what visual studio was doing (Include only process name devenv.exe) and look for result Access Denied. It will tell you what registry key is not accessible.
In my case it was the regkey HKCR.webtest (HKEY_CLASSES_ROOT.webtest) that caused the problem. Taking ownership and assigning acces to this solved my problem.
I do not know how the root cause of the problem.
The above didnt work for me as I kept being denied in regedit even though i was admin.
I found this on another site:
psexec -i -d -s c:\windows\regedit.exe
psexec is available from Microsoft here
http://technet.microsoft.com/en-us/sysinternals/bb897553.aspx
This gave me full registry access. I tried to give admin owner to specific keys like above but VS 2012 express was still throwing that registry permission error. So I finally just added Administrator to the permission list of the entire HKEY_LOCAL_MACHINE\SOFTWARE\Classes\ directory in regedit. Then gave admins full control.
This worked. I can now create a project without that infernal error!
This issue has nothing to do with permissions in the context discussed. The issue is caused by an incorrect path to the template files in the registry due to sloppy installation program testing by Microsoft. The incorrect path throws an error when a user tries to start a new project and, true to Microsoft style, displays a generic and meaningless error message about permissions.
Here's the issue specifically. In some machines (assuming C: is the primary drive and user1 is the user's login name and version 2013) the location of the template files is C:\users\user1\my documents\visual studio 2013\projects. Unfortunately, the installation path written by the installer in the registry is C:\users\user1\documents\visual studio 2013\projects. So, it's pointing to \documents while the correct location is \my documents. To be sure, look where your visual studio 2013\projects folder is located - either documents or my documents - and change the registry key to the correct location.
For my example the key is at HKEY_CURRENT_USER\software\Microsoft\VisualStudio\12.0\NewProjectDialog\MRUSettingsLocalProjectLocationEntries the path is located in the Value0 entry. Check it and change to make it point to exactly where your project folder is.
Lars Meldgard's use of ProcMon was a good tip and helped me. I just wanted to include a picture of what an access denied looks like in ProcMon. I had to do it one registry key at a time--this wasn't the only one. It was very cumbersome and slow, but I was able to knock them off one by one and give full rights on each one. (That part is a hassle too, because I had to take ownership, then close regedit, then go back in so I could set the permissions; you can't do it all in one fell swoop.)
During solution deployments & Feature activation, I am facing an on/off issue where the system is unable to find & load the FeatureReceiver class. Mostly it is file not found exception (even though the assembly is there in the GAC). I checked over the net and this seems it a common issue with solutions (wsp) packaging DLL to be GACed. (But, no one has any clue or solution!)
What is the recommendation and guideline to fix this issue? We are setting the flag to reset IIS in my solution definition - but that does not seem to help. The issue is more prevalent in multi-M farms.
Thanks
This is a general problem in SharePoint in cause of the "SharePoint 2010 Timer Service". Because this one caches the wsp's and during the deployment or feature activation old references will occurres this error!
So try the following link. I hope this solution will help you.
http://msscorner.de/en/2011/10/27/sharepoint-deployment-failed-to-create-receiver-object-from-assembly/
First try the solution linked to by Falco...
If that does not help, try this:
Open the event-receiver file created by sharepoint
Compare the GUID above the event-receiver-class with the one stated in the stack-trace "...class=7g3562-438dn4...
If it does not match:
Copy the content of the class
Delete the file
Create a new file by right-clicking the feature -> add new event reciever
Pass the content
First thing, you dont need to give iisreset as your wsp deployment would have already done that.
Can you check if the assembly name, version, public token specified in the feature.xml is same at the actual assembly that is deployed in gac? I am thinking there is mismatch in assembly signature