Lazycoder

24Mar/040

SQL Reporting services is working on my dev machine

I finally got SQL Reporting services working. Yay! Turns out the culprit(s) were a BUNCH of artifacts in the Private Assemblies folder. Once I deleted them with reckless abandon (any other plugins I have installed can go fish if it means I get to use the Reporting Services) I was able to create a new Reporting Project. Here’s the newsgroup post I made in the “SQL Server Reporting Services” newsgroup

I had a couple of problems installing the SQL Reporting services tool. Mainly related to extra assemblies left behind in the Private Assemblies folder by plugins (a ReSharper Beta was the biggest culprit, it doesn’t uninstall cleanly).

My first problem was an error message when creating a new Report Project “The located assembly’s manifest definition with name “Microsoft.VisualStudio.Shell.Interop” does not match the assembly reference.”. This was solved by deleting the Microsoft.VisualStudio.Shell.Interop.dll left behind by ReSharper in the Private Assemblies folder.

The second problem I had was an error message telling me “application for project type rptproj is not installed”. This was also caused by some dll in the Private Assemblies folder. This time I didn’t mess around, I just deleted all the dlls in that folder with reckless abandon. I’d love to know which specific assembly might cause that error though. There were 3 or 4 dlls that started with “Microsoft” in there. It could possibly have been one of those.

After I cleaned out the Private Assemblies folder, I was able to create a new Reporting Project. I may uninstall the Reporting Services tool and re-install it in case I deleted any assemblies required for it from the Private Assemblies folder.

You can read more about them here:

http://www.lazycoder.com/weblog/wp-trackback.php/45

and here:

http://blogs.sqlxml.org/bryantlikes/archive/2004/02/26/390.aspx?Pending=true

So, it’s not entirely Microsoft’s fault. The error messages could have been a little more clear. But could they? Can you really anticipate stuff like this?

I would advise anyone having problems installing a VSIP or the Reporting Services package to check out your Private Assemblies folder.

On another note: Does anyone know of a tool that will let you view the dependancies for a given assembly/executible and their physical location on the hard disk? I’ve seen lots that tell you the version # and the assembly name, but not where they are located.

Update: Albert Yen responded to my newsgroup posting telling me that the SQL Reporting Services tool does not install anything in the private assemblies folder.

We do not install any files in the Private Assemblies directory. There are
several versions of Microsoft.VisualStudio.*.Interop floating around and
they would cause conflicts if any of them were found in the Private
Assemblies directory. We specifically avoided this directory because of the
potential for such conflicts.


Albert Yen
SQL Server Reporting Services

This posting is provided “AS IS” with no warranties, and confers no rights.

19Mar/040

OK, I’m done trying to use Report Services

It’s getting uninstalled. It never worked in the IDE, there aren’t any samples installed on the server when it’s installed.

It’s pretty useless from what I can tell. People wonder why I’m not an “early adopter”? I can’t even get the RTM stuff to work correctly, why would I want to mess with alpha and beta bits? I haven’t had this many problems with MS dev tools ever, the quality has really shot down since VS 6.0 in my opinion.

Filed under: .NET, Database No Comments
1Mar/040

Security and ASP.NET

Julia Lerman Blog – Don’t Be Iffy…

Julia Lermen has been preparing for a presentation she is giving on ASP.NET security. It’s been an eye opener for her. It usually is for me too. That’s why, even though I know I’m going to have to sit through 30-45 minutes of “check your inputs”, I continue to go to every web security presentation I can. There is always an extra nugget of information that I didn’t know before. If there isn’t, I automatically label the presentation as “a newbie presentation”. “Pre-school security”. :)

Don’t we all? Isn’t it what we were told to do. ASP.NET protects the web.config file so nobody can browse to it and see your connection strings, logins and passwords and whatever else you have hidden in there. Right?

But guess what, that’s just not good enough anymore! Hackers who know how to get into your webserver and get around asp.net can get at the web.config file.

That’s kind of like the old mantra, “If you’re running untrusted code under the root account on your box, it’s not your box anymore”.

There are lots of things you can do to mitigate the severity of a compromised database not storing any passwords in clear text and encrypting personal information (CC numbers and that sort) is a start. Sequestering the DB’s on a separate subnet behind a firewall is another idea.

Whenever I think about the security necessary for my application or system, I think about Dana Epps 8 rules of security.

http://silverstr.ufies.org/blog/archives/000468.html

Filed under: Database, General No Comments