The painful way of migrating to dotnet


Recently I started to checkout the newer version of Microsoft dotnet. However, the tooling [Visual Studio / VSCode] were all like, you have to be connected to the internet and also need to be updated. Few of the packages are moving the bleeding edge, the remaining still lagging behind.

As a normal developer that is used to .Net Framework 4.7, it really is a worst experience, as you get all weird errors, but no help from Microsoft groups. I ran into this while running a test case in XUnit where there is a huge mess. I made a simple check-in for ASP.NET Security which took 1 hour but trying to setup debugging and running the tests have taken approx 2 days and not yet successful.

Given this much pain, it will be worth moving to a different language and trying to get up to speed as I was never expecting Microsoft to screw up the developer’s life so bad with the newer versions.

Advertisements

How to debug OWIN related stuff using Symbol Source


I ran into a situation today wherein I was required to debug the Google Authentication middleware built on top of OWIN.

I already had the code checked out from Katana project in CodePlex. However, when I tried to use, it was the latest bits [dev channel]. My app was using the version 2.1 and the dev version was in 3.0.

Tired of searching the tag for the version 2.1, I came to know that the symbols for the various open source projects are made available from SymbolSource.org

Given this piece of information, I read the steps on how to configure the symbol server in Visual studio and then upon successful source registration, I was able to step through the middlewares and do the debugging stuff.

Things that I did were,

  1. Grab the public [authentication less uri access] from Symbol Source [http://srv.symbolsource.org/pdb/Public%5D
  2. Go to Tools -> Options -> Debugger -> General.
  3. Uncheck “Enable Just My Code (Managed only)”.
  4. Uncheck “Enable .NET Framework source stepping”. Yes, it is misleading, but if you don’t, then Visual Studio will ignore your custom server order (see further on) and only use it’s own servers.
  5. Check “Enable source server support”.
  6. Uncheck “Require source files to exactly match the original version”
  7. Go to Tools -> Options -> Debugger -> Symbols.
  8. Select a folder for the local symbol/source cache. You may experience silent failures in getting symbols if it doesn’t exist or is read-only for some reason.
  9. Add symbol servers under “Symbol file (.pdb) locations”. Pay attention to the correct order, because some servers may contain symbols for the same binaries: with or without sources. We recommend the following setup:
    1. http://referencesource.microsoft.com/symbols
    2. http://srv.symbolsource.org/pdb/Public or the authenticated variant (see above)
    3. http://srv.symbolsource.org/pdb/MyGet or the authenticated variant (see above)
    4. http://msdl.microsoft.com/download/symbols
  10. These steps are highlighted in the Uri [http://www.symbolsource.org/Public/Wiki/Using]
This saved me a lot of time than hunting for the specified tagged version and to build them and then use it.
 
Hope this helps

PathTooLongException during installation of VSIX packages in Visual Studio 2010


There is a fix, but you have to get your hands dirty 😉

1.take the vsix file, open with zip or rar, extract to a convenient location, open the extracted folder,

2.open the extension manifest with notepad, change the name inside the name tag

<?xml version=”1.0″ encoding=”utf-8″?>
<Vsix xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance” xmlns:xsd=”http://www.w3.org/2001/XMLSchema” Version=”1.0.0″ xmlns=”http://schemas.microsoft.com/developer/vsx-schema/2010“>
<Identifier Id=”VisualStudio.FeaturePack.Runtime.6077f06b-77df-4c5e-975a-97eb5b6e26b5”>
<Name>Vis</Name>
………………………

3. zip the complete folder, rename the zip file extension to vsix

4. click on vsix and execute.

Tracked back from http://smartclient.codeplex.com/discussions/215292