I have these CLR types installed on my local https://puu.sh/yEWG5/b4f77fba7b.png
Also, I have SQL server 2016 installed on my local system but when I try to run the project I get error as below
https://puu.sh/yEWQm/78a4220830.png
Can someone help? I tried installing latest nugget package from https://www.nuget.org/packages/Microsoft.SqlServer.Types/ but it did not help.
Though I am able to add a column of type geography in a table in my local database. It fails at runtime when I run my project and error comes as below
https://puu.sh/yEWQm/78a4220830.png
According to the docs if you have installed the CLR Types it should load from the GAC so I'm not sure why that didn't work for you. (I would check that you have the correct version as your dependency)
However, we do use the SQLServerTypes in our app without installing the CLR types by using the following method (this method is described in the readme.htm that comes with SqlServerTypes).
Grab the SqlServerTypes.nupkg and extract it to a folder lets call this folder SST from now on.
(Locations of the files I talk about in the following steps may differ from version to version but, the principle is the same)
Create a SqlServerTypes folder in your project
Copy the SST/nativebinaries/x86 and x64 folders into your new SqlServerTypes folder
Also copy the files from SST/content (you should see Loader.cs and readme.htm) into the SqlServerTypes folder.
Now all you need to do is call the Loader when your app boots up.
We do this during our autofac setup by making this call.
Utilities.LoadNativeAssemblies(AppDomain.CurrentDomain.BaseDirectory)
You may need to adjust the param passed into this method to work with your application. If the correct path is used you should have access to the spatial types in your code.
edit: It may be possible to just call the LoadNativeAssemblies straight away (and avoid all the work I posted above) if you have installed the nuget package in your app but, I have not tested this as we are stuck on an old version of SqlServerTypes.
Because i cannot put a comment i have to put a answer, you can check that, that article and this, this, this and this answers, i hope they guide you to someting usefull.
Related
I'm trying to follow the directions to setup olingo-odata4-js on a windows 8 machine.
http://olingo.apache.org/doc/javascript/project-setup.html
First Problem
After installing the main modules navigate into the folder /grunt- config/browserify_transforms/stripheader and call again npm install
But there is no such directory anywhere in the cloned repo.
Second Problem
When I open up the solution in Visual Studio, the gnuget package manager asked to restore the packages. However, the following error occurs: "unable to find version 6.0.0-beta1 of package Microsoft.Odata.Service"
Anyone successfully go through the setup? Everything looks clean and well written. I'm sure I'm just missing something.
it is a bit long story about the missing Microsoft.OData.Service 6.x, it does exist but is not officially released to public. unlike Its previous version that is for odata V3 protocol, 6.x library is for odata V4 protocol, since Microsoft OData team decided to move away from WCF Data service, and instead wanted to recommend RESTier for OData V4, so 6.x's service dll was not released.
that is why Apache Olingo doesn't make it public either. but if you need, we can provide private bits to you for running olingo-js tests (as a temp solution).
In an MVC app I am working on, we've recently began using ActiveReports 7 for our report-generating needs. On my local machine, everything works great. However, when we deploy to our Dev server for team-level testing, we get a LicenseException:
License for the SectionReport cannot be found.
We followed the user guide here to attempt different ways to resolve the problem.
What we have done:
Ensured that the licenses.licx file references the assemblies, and that the correct ActiveReports 7 assemblies are being built with and referenced by our project. As it stands, the licenses.licx file looks like this (sans the line-breaks):
GrapeCity.ActiveReports.SectionReport, GrapeCity.ActiveReports.v7, Version=7.0.6158.0, Culture=neutral, PublicKeyToken=cc4967777c49a3ff
GrapeCity.ActiveReports.Export.Pdf.Section.PdfExport, GrapeCity.ActiveReports.Export.Pdf.v7, Version=7.0.6158.0, Culture=neutral, PublicKeyToken=cc4967777c49a3ff
As this is a MVC web project, used the Assembly License Generator that comes with AR7 to create an [Assembly].Web.License.dll library, which we are building with the project in a /lib/ directory at the solution-level. This change had no effect on the License exception.
Used the Web Key Generator to create a key for the App.config file. This change had no effect on the License exception.
What we have not done:
Created some web form, and created an App_License.dll library that gets built with our project. The reason we did not do this is we are not using Web controls for our reports, we are not even using the GrapeCity.ActiveReports.Web assembly, and the error is not coming from any class in that library (which is logical, seeing how we're not using it.)
The only notable detail of all of this is that modifying the licenses.licx file had an early effect as we had a similar license exception on another component; ensuring that licenses.licx had the proper details ensured that that other component was no longer throwing LicenseExceptions in our app. I tentatively think from this that maybe my licenses.licx file still lacks something needed to make this app work.
The only thing remaining I can think to do is to recommend our lead license our server as a developer, but this possibility has already come up, and the direction we've been asked to take is to avoid that route if at all possible. I think it is possible because I have encountered similar posts involving people who followed the steps in the user guide above and presumably were able to solve the issue. Yet, for my team, these steps aren't working.
Question: What am I missing?
Using the Assembly License Generator as you have done should do the trick. Also, make sure that you are using the latest version of AR7 as according to this post on the ActiveReports 7 Support Forums, there was a fix done to some later version of ActiveReports 7 to correct some problem with licensing in this scenario. Specifically the steps given from the previously cited post said that following the below steps with the updated version corrected someone else's problem:
Run the program "ApplicationLicenseGenerator.exe" (as Administrator) from a location similar to "C:\Program Files\Common Files\ComponentOne\ActiveReports Developer 7\"ApplicationLicenseGenerator.exe"
Browse to the compiled ActiveReports DLL.
Press the "Generate" Button.
This generates a satellite assembly similar to yourclasslibraryname.dll.GrapeCity.Licenses.dll
Place the DLL in the bin folder of your web project and/or reference the generated DLL in your web service project.
Answer: for non-licensed users, [Assembly].GrapeCity.License.dll must be added to the web project as a reference!
Licenses.licx matters from a build perspective, though. But the license file was not missing anything.
I'm trying to use the latest Exchange Web Services DLL, however when I search my hard drive I see many versions of Microsoft.Exchange.WebServices.DLL, the most recent being version 14.0.650.7 with a date of 1/24/12.
I want to rebuild my machine but can't find an official place to get this DLL. I attempted to download the latest SDK I don't see any DLL to use, nor is there any CHM for me to use.
Where can I get the latest version of Microsoft.Exchange.WebServices.DLL?
Current version of the EWS Managed API is 1.2. It seems that Microsoft sometimes forgets to update links to the newest download which makes it hard to find out what the newest version is but I usually go to www.microsoft.com/downloads and search for "Exchange Web Services Managed API" whenever I need a fresh download.
UPDATE:
EWS is on NuGet:
http://www.nuget.org/packages?q=EWS
This is an old question, and the two answers by the OP and #JakobChristensen do answer the question. I'll just mention that I'm finding the situation fairly confusing.
I recently (manually, not via NuGet) downloaded the current NuGet version, which they currently call "2.2.0".
https://www.nuget.org/packages/Microsoft.Exchange.WebServices/
But the internal file/product version on the .dll is 15.00.0913.015.
According to this page
https://msdn.microsoft.com/en-us/library/office/dn528373(v=exchg.150).aspx
the file should be placed here:
C:\Program Files\Microsoft\Exchange\Web Services\2.0\
So that's where I placed it. Later, when playing around with a Microsoft sample program I noted that it did indeed reference the file at that location.
But another Microsoft sample program referenced the file in the GAC!
C:\WINDOWS\assembly\GAC_MSIL\Microsoft.Exchange.WebServices\15.0.0.0__31bf3856ad364e35\Microsoft.Exchange.WebServices.dll
This version had file/product version 15.00.0847.030.
I'm not sure how that file got there, probably part of a Visual Studio installation.
There's also something called EWSCore, which is apparently a forked version of the official EWS with some bug fixes.
https://www.nuget.org/packages/EWSCore/
My current decision is that I'll consider the official NuGet version to be the version I'll standardize on, and manually download it to my development PC and my build PC and place it here:
C:\Program Files\Microsoft\Exchange\Web Services\2.0\
Options
If you use .net framework, there is a nuget package "Microsoft.Exchange.WebServices 2.2.0" here https://www.nuget.org/packages/Microsoft.Exchange.WebServices
If you use .netstandard/.net5+, you need to go the Github open source project "OfficeDev /
ews-managed-api" here https://github.com/OfficeDev/ews-managed-api , and there you download the code, and compile it. However, this project is targeting .net3.5. So, you need to convert/upgrade it to .netstandard/.net5+ manually and compile it for your self.
!! Update !!: I took the version as of date of this post from GitHub. Replaced Old Style project with SDK project. Target framework set to netstandard2.0. Added packages System.DirectoryServicesandSystem.Security.Cryptography.Xml. In files, I had to remove few namespaces that not compatible, but were not used. Removed AsImageinPhoto, this is public image retrieving method, not needed - it only converts byte array. And fixed loading issue with Assembly.GetExecutingAssembly().GetTypes();`
Type[] types;
try
{
types = Assembly.GetExecutingAssembly().GetTypes();
}
catch (ReflectionTypeLoadException ex)
{
types = ex.Types.Where(t => t != null).ToArray();
}
I also deleted or excluded from project bunch of files related to documentation, fxcop, and assembly info.
And then it worked for sending emails with different API versions. Reading emails is not tested yet.
There is a third option. Nuget has a package "Microsoft.Exchange.WebServices.NETStandard 2.0.0-beta3" But this is not an official Microsoft code. https://www.nuget.org/packages/Microsoft.Exchange.WebServices.NETStandard/2.0.0-beta3
!! Update !!: Got this version and compared to the original code in option #2. This code has more changes than necessary to convert to .netstandard. It has some async stuff added.
I recently installed the EF4.1-Update. When I made a new MVC3 Project and tried to add the MvcScaffolding using the PackageManagerConsole in VS2010 it wouldn't install it. Has anyone else
seen this? I removed the EF4.1-Update from my machine and MvcScaffolding installs correctly.
thanks,
Bill44077
You might have to clean out the packages folder in your solution and reinstall the MvcScaffolding. Once you do this everything should sync back up.
Good luck and hope this helps some.
It does work. And it works beautifully
But I had some issues getting it all setup.
What error(s) did you get exactly I had a number of issues, but solved them one by one.
Did you get this sort of thing in PMC when VS started up?
The following error occurred while loading the extended type data file: Microsoft.PowerShell.Core, C:\Windows\SysWOW64\WindowsPowerShell\v1.0\types.ps1xml(2943) : Error in type "System.Security.AccessControl.ObjectSecurity": Exception: Cannot convert the "Microsoft.PowerShell.Commands.SecurityDescriptorCommandsBase" value of type "System.String" to type "System.Type".
If so either update .net Refelector (now costs), or go Tools > Add-In Manager and disable the .NEt Reflector add in ! THEN RESTART VS
Or if you try to scaffold something, do you get e.g.
Invoke-Scaffolder : A parameter cannot be found that matches parameter name -ModelType"
?
Do you get errors when you try to add a controller to your MVC 3 project?
Are you running on Windows (pre 7) + without powershell 2.0 installed?
Basically don't worry it does work, I think the order or installations matters, just work through it bit by bit, its worth it.
Did you try reinstalling the update after the scaffolding is installed? I already had the scaffolding installed when I installed Update 1, so i did not see a problem.
I've had this problem before when the scaffolding.config file was either not present, or not filled with the Default Scaffolders -- make sure its populated with the default entries for views, controllers, etc. I think there is 9 by default in version 1.0.9.
Old post I know but this is still relevant in project templates and autogenerated projects -- the scaffolding.config needs to have its defaults.
I am trying to get started in development of my website and plugins using Umbraco. When I download the binaries from Codeplex, the installation and running of the website works fine. When I downloaded the source code, All I get is a login screen even when the web.config files are the same. Am I doing something wrong or is there something I missed.
The path I use to map IIS to is
branches\4.1.0\umbraco\presentation
You need to compile the source code to get it to work.
To be honest, you shouldn't need the full source unless you really want to start hacking around in the core (which may cause you problems with future updates) or you want to see how stuff works. The Umbraco framework is pretty extensible, I've not found too much so far that I couldn't do without having to touch the core source.
I had a similar issue when running the source and that was that the hashing of the admin password did not work. So i debugged it to see what value was expected and then changed it in the database.