I have been given a copy of a production DTSX package that needs amending. I have moved this into my development pc. The DTXS package contains a ScriptTask object only. In this ScriptTask there are References to Microsoft.Exchange.WebServices.dll and Microsoft.Exchange.WebServices.Auth.dll both of which have yellow exclamation marks:
I have found the DLLs online and installed them:
When I search for them in References they are still not listed:
When I use the Browse option and search for the folder it returns no items:
I tried to register the DLLs and got a message saying they didn't need registering.
Can someone please help.
Thanks
Rob
I think I had the wrong version of the Exchange Web Services DLL. I following the following link and fixed the issue:
https://blog.devoworx.net/2016/03/01/an-error-occurred-while-trying-to-load-a-required-component-please-ensure-that-the-following-prerequisite-component-is-installed-microsoft-exchange-webservices/
Cheers
Rob
Related
I created my own Nuget Server following the documentation and I got it, but I cannot access the packages from Visual Studio 2019 Community Nuget Package Manager.
So, when I do it through a browser I get this, which seems fine:
When I click on "here" to view the packages I see the test one I added, and if I click it I can even download it:
However, when I access by Visual Studio I get this:
The full error says:
[Nuget Server] The V2 feed at
'http://mywebsite.com/NugetServer/Packages/Search()?$filter=IsLatestVersion&searchTerm=''&targetFramework=''&includePrerelease=false&$skip=0&$top=26&semVerLevel=2.0.0'
returned an unexpected status code '404 Not Found'. But I can't figure
out why.
This is how I added it to the Nuget Manager:
This is the folder structure of the site:
As you can see the package test.1.0.0.nupkg is where the NugetServer project told me to put it.
I tried several things:
Giving Everyone FullControl of the folder (because at the beginning I got 403 Forbiden instead of 404)
Changing the folder structure, puting the nupkg package inside a folder named nuget, put the whole Packages folder inside the nuget folder and other things I saw as solutions in other Stackoverflow threads.
Transforming everything to VB as this Stackoverflow thread suggested.
Changing IIS parameters
Nothing worked for me, so I need a bit of help to find the way.
Maybe I need something for the "Search()" to work? I'm lost.
If you need more info I can provide, just ask, please.
Please go to Tools > Nuget Package Manager > Package Sources and check the resource is https://api.nuget.org/v3/index.json as below:
Nothing worked for me, so I need a bit of help to find the way.
Maybe I need something for the "Search()" to work? I'm lost.
If you need more info I can provide, just ask, please.
First, since you can get the nuget package and view the package on your local website according to this document, I'm sure you have no problem with the steps to create your own nuget server.
The main reason is that you use the wrong link such as the view package in the Package Source. Instead, you should use the Repository URLs which is specified. The error is just it cannot
Repository URLs
In the package manager settings, add the following URL to the list of Package Sources:https://xxxxxxxxx/NugetServer/nuget.
Adding packages
To add packages to the feed put package files (.nupkg files) in the folder D:\xxxxx\xxxx\NugetServer\Packages
So please refer to the related info in your PC.
Update 1
Sloution
1) put the nuget packages into your local path like D:\xxxxx\xxxx\NugetServer\Packages so that you can access the packages through your links.(do not create any other new folders and put packages into them)
2) change the package source to http://xxxxxx/NugetServer/nuget as Repository URLs in your PC saids.
Update 2
In addition, please do not forget to run the instance of the NugetServer project at the same time and when the first screenshot that you provided shows, you should follow the guidance of it.
Hope it could help you.
I have inheritted several old VB6 applications that currently cannot be rewritten in .NET. These old applications all use ADO, and compile fine on my XP machine. Since switching to a Windows 7 machine, the applications compile fine, but when they are deployed (on XP machines), I get errors. This is a known issue that this Microsoft article discusses:
http://support.microsoft.com/kb/2517589
The article give a very detailed explanation of a workaround, which involved copying a ".TLB" file and registering it using "regtlibv12". When I attempt to register it, I get this error message:
RegisterTypeLib of C:\Program Files\Common Files\System\ado\msado60_Backcompat.tlb failed : 80029c4a
I have also tried registering this using the old "regtlib.exe" in the Windows folder, but got this error:
LoadTypeLib of C:\Program Files\Common Files\System\ado\msado60_Backcompat.tlb failed : 80029c4a
Because of this, I cannot continue with the work around. I would greatly appreciate any guidance anyone could give me on how to properly register this file.
Thank you in advance!
Put the .TLB file in an appropriate place like
C:\Program Files\Common Files\System\ado
Then open a new Project in the VB6 IDE (elevated, i.e. as admin). Choose Project|References... then click the Browse button. Navigate to the new .TLB file and open it. Check the box to select the item and close the References dialog.
It should be registered now.
If desperate, try VB Type Library Registration Utility.
You probably downloaded the file as C:\temp\Msado60_Backcompat_i386.tlb and didn't rename it. The example is for registering C:\temp\Msado60_Backcompat.tlb (note, no _i386).
Run the command with the correct filename.
Just to update this answer list based upon more recent information, Microsoft released KB 2640696 which addresses this issue in a more straightforward manner. This patch makes it much easier to deploy on your build machines and solves the downlevel OS issue as well.
A more complete picture of the patch can be found on the following blog post.
I have been trying to publish my service to windows azure. The service consists of a single webRole, however I have added remote login functionality published it and built it a few times, and now all the sudden it will not build. The reason it gives is that
Details below:
"Error 56 The specified path, file name, or both are too long. The fully qualified file name must be less than 260 characters, and the directory name must be less than 248 characters. C:\Program Files (x86)\MSBuild\Microsoft\Cloud Service\1.0\Visual Studio 10.0\Microsoft.CloudService.targets 202 5 FileSystemCreator"
I have gone on all the forums, I have used CSPack command line for packaging the service which is fine but I'm having a really hard time configuring the certificate for remote desktop connect and I would like to take advantage of this feature as I am creating some websites in the onStart event and I would like to peek into IIS. Some microsoft employees do agree that this is a bug and the have promised a fix this issue, refer to post . I am using VS2010 and I do not know how to fix this bug.
Can anyone please help, or point me to a place where I can get any help.
I ran into the same problem with a new solution.
Note that, unlike Eugenio Pace's response suggests, the error occurs only when deploying to Azure (and not when running the project in the Azure Compute Emulator).
Try adding the following line to the first property group of your Windows Azure Visual Studio Project file (*.ccproj):
<ServiceOutputDirectory>C:\Azure\</ServiceOutputDirectory>
The trailing slash (for whatever path you select) appears to be required. This folder will be deleted each time you create a package if it exists.
This setting seems to redirect the working folder for the package to a shorter base path, preventing the path too long error.
Credit goes to: http://govada.blogspot.com/2011/12/windows-azure-package-build-error.html
Perhaps the local folder used to store temporary development fabric is too long. See Windows Azure - Resolving "The Path is too long after being fully qualified" Error Message.
I was having this problem as well when deploying a Node.js project to Azure.
To fix it, I had to change my "TEMP" and "TMP" user environment variables to something shorter than their default values.
In my case, they were pointing by default to %USERPROFILE%\AppData\Local\Temp, changing them to C:\Temp solved it.
Make sure you restart Windows after.
The better solution may be to create a symbolic link to your project folder. This doesn't require moving files or changing system variables. Open up the command prompt as an administrator and run this:
mklink /D C:\Dev C:\Users\danzo\Source\Workspaces
Obviously you can change "C:\Dev" to whatever you want it to be and you'll need to change the longer path above to the root directory of your soltions/projects folder.
Same problem happened to me when I try Packaging an Umbraco project for Azure (https://github.com/WindowsAzure-Accelerators/wa-accelerator-umbraco/wiki/Deployment), I found the solution is to: Copy and rename the long-name path and folder to "C:\someshortname".
(solution was suggested by this: link)
I tried all the above 2 approaches:
-change TEMP and TMP enviromental variables
-<ServiceOutputDirectory> path
and didn't work.
In my case, I had to move the whole project to a shorter path C:\ and worked.
I'm using W7 and VS12.
When you run a cloud service on the development fabric, the development fabric uses a temporary folder to store a number of files including local storage locations, cached binaries, configuration, diagnostics information and cached compiled web site content.
By default this location is: C:\Users\\AppData\Local\dftmp
Credit goes to Jim Nakashima of Microsoft :
https://blogs.msdn.microsoft.com/jnak/2010/01/14/windows-azure-resolving-the-path-is-too-long-after-being-fully-qualified-error-message/
In order to change the temporary folder, a user environment variable has to be created :
It is named _CSRUN_STATE_DIRECTORY
Give it a value of short named directory like :
c:\AzureTemp
Don't forget to restart Visual Studio in order to have the environmennt variables to be read again
It fixed many compilations problem !
I am creating an installation package for a VB6 application using Visual Studio Installer from the Visual Studio Installer Enterprise Tools v6.0. My issue is that Installer is adding a strange item under depdendencies, named simply "3". The "Sourcefile" and "Target" properties for this item are also shown as just "3". The "ComponentId" property values shows a GUID of "{EC1441E1-073C-4AD6-886F-1C6C6E998CAD}", which doesn't show up in a search within regedit on my PC. I'm not able to identify anything within the references or components of the VB6 project that would explain a dependency on a file named simply "3".
Has anyone seen this before, or have some insight as to where that dependency might be coming from?
Thanks in advance for any replies.
May be some maleware COM component! Do a thorough scan of your computer with a good antivirus.
And oh yes if it isn't malware then unregister the dependency from the registry using
regsvr32 /u <offending guid>
and then re-run your application to see if it crashes (do a thorough test) if not then you dont need it. If it does then debug and find out who is using it.
No malware - searches on the net found others with the same issue, but no resolutions. Builds done since then no longer have the dependency, so it remains a mystery.
I just added xUnit to our test project (for the Asserts, we're still using MSTest as the framework) and immediately the test runs refused to execute any of the tests. This is the error message:
Failed to queue test run '{ .... }'
Test run deployment issue: The
location of the file or directory
'...xUnit.dll' is not trusted.
It took me a few tries to find the answer in Google, so I'm putting it here in case anyone else runs into the same problem. A detailed description can be found at this blog posting.
Basically, the fix invovles right-clicking on the dll file (xunit.dll for example) in Windows Explorer, going to Properties, and clicking "Unblock" at the bottom of the tab next to the 'Security' text. It seems that Vista / Windows 2008 will automatically mark assemblies that come from other machines or the internet as unsafe.
As a couple commenters have mentioned, you may also need to restart Visual Studio for this to take effect.
In my team we had the same problem.
Your solution didn't work, but this post by Charles Sterling did help.
We used the following line:
caspol -machine -addgroup 1 -url file://\\server/share/* FullTrust -name DevShare
After having this issue and burning hours trying to get "Unblock" to stick longer than a few minutes and/or figuring out caspol to no avail, I finally found a little tidbit via Google that the assemblies will be blocked again the next time you build or rebuild the project, since they're re-copied from their original source location. (I guess I never noticed that this happened before with references assemblies, but anyway...)
My fix for this was the following:
Copy all the needed DLLs to another
spot for safe-keeping
Remove the
references in Visual Studio
Physically delete the DLLs in the
bin folder
Unblock the DLLs
individually in the spot where they
were copied off
Add the references
back in Visual Studio from the
holding spot
Every subsequent build or rebuild worked fine afterward.
Running on an XP machine (even with .NET 3.5 SP1 installed) I was not able to get any of the other solutions listed here to work.
However working from the same post by Charles Sterling that Davy Landman references, I finally succeeded with this variation:
Run the .NET 2.0 Configuration tool (Settings... Control Panel... Administrative Tools... .NET Framework 2.0 Configuration)
Click down to "My Computer ... Runtime Security Policy ... Machine ... Code Groups ... All_Code"
Create a new code group with membership condition of "Zone"="Local Intranet" and assign the permission set "FullTrust"
Restart Visual Studio
After these steps I am able to run tests, including after restarts and rebuilds.
EDIT: as described in this answer, you may need to install the .NET SDK (which is different from the .NET framework) in order to have the .NET 2.0 Configuration tool on your system.
I had the same problem with moq. But would not 'unblock'. Every time I unblocked it, it was still blocked!?!?
I had to unblock the original zip file I downloaded. Then copy the DLL from the zip file again. It work after that.
It may seem really obvious now, but when I was clicking unblock the file was set as read-only.
Only after un-checking that attribute, applying, then selecting unblock did I actually get this working.
Give that a go.
:)
PS: I also deleted all the old dll's in my bin folder, just to make sure Visual Studio wasn't picking up the old one.
I had the same problem with downloaded DLLs blocked by Vista.
You need Administrator rights to get the "Unblock" button on the file's Properties.
I simply replaced the DLLs with the latest version from source control (TFS) where I had committed them before.
Go to file
Right click and select Properties
On the first Register click on Allow
I also tried opening the file in notepad++ and renaming it.
Slightly different approach, but it worked for me. The local file system then think it comes from the same machine.
It's not just the moq.dll that needs to be unblocked. The latest zip file includes an moq.xml and moq.pdb file - referencing the dll copies these other two files to the bin folders as well. If all three have not been unblocked the tests won't run, I found.